运行 django 时，Twisted 服务器意外崩溃

Posted 2023-02-23

【中文标题】运行 django 时，Twisted 服务器意外崩溃

【英文标题】：Twisted server crashes unexpectedly while running django

【发布时间】：2012-05-02 21:37:11

【问题描述】：

我正在使用来自this site 的 django-on-twisted 脚本在 twisted 上运行 django 应用程序。

所有请求都由 nginx 服务器提供服务，该服务器将相关请求反向代理到twisted。我有一个 API 的 url 设置，它基本上只接收 get 请求并在发送响应之前对 get 参数进行一些处理。但是，当特定客户端访问 api 时，扭曲的服务器就会关闭。下面贴的是 Nginx 日志：

the.ip.of.client - - [21/Apr/2012:11:30:36 -0400] "GET /api/url/?get=params&more=params HTTP/1.1" 499 0 "-" "Java/1.6.0_24"

此时，扭曲的原木只显示扭曲停止工作。通过错误代码 499，我假设客户端意外关闭了连接，我对此没有任何问题。客户是否收到响应对我来说并不重要。这是相关的django视图：

def api_url(request):
    if request.GET:
        get_param = request.GET.get('get', [''])[0]
        more_param = request.GET.get('more', [''])[0]
        #some processing here based on the get params
        return HttpResponse('OK')
    else:
        raise Http404

来自客户端的请求是有效请求，不会对处理产生不利影响。我已经从外壳测试了它。当我在 django 开发服务器上尝试它时，它也以同样的方式崩溃，没有留下任何接收请求的痕迹。从浏览器测试时，一切都运行良好。此外，twisted 服务器适用于所有常规用例。这是我第一次遇到它的问题。任何帮助或指点将不胜感激。

【问题讨论】：

“关闭”是什么意思？它是否干净地退出？信号会导致它退出吗？

twisted 服务器不会向日志中写入任何内容。我很确定这不是一个干净的出口。它只是停止工作。知道我如何能够捕捉到退出信号吗？

如果您使用的是 bash，那么$? 会有所帮助。从 bash 手册页：?扩展为最近执行的前台管道的退出状态。 例如，twistd ...; echo $?

@tapan 刚刚阅读 peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi 。也许你会选择 uWSGI :)

这里有一个问题：如果你真的注释掉“这里基于get params的一些处理”，它仍然会出错吗？如果是这样，那么问题很可能出在 Twisted 或服务器或配置上。缺乏相关的更广泛背景，这里没有人可以在没有自己过去遇到同样问题的情况下进一步诊断。如果没有，那么它与您在问题中省略的代码有关，因此这里没有人可以帮助您提供您在这种情况下提供的信息。但是，至少这会告诉我们需要哪些额外的细节。

【参考方案1】：

您说问题出在客户端点击特定网址（可重现？） 由于它适用于 gunicorn 但不适用于 django-on-twisted，因此脚本无法正常运行或 twisted.web2 是问题所在。

请尝试$ sh init.sh yourdjangoproject stand。

你也可以尝试修改run.py来捕捉SystemExit：

import pdb
try:
   # __main__ stuff here.
except (KeyboardInterrupt, SystemExit):
   pdb.set_trace()

【讨论】：

感谢您的回答！因为我们已经转移到一个全新的架构，所以我真的无法对此进行测试。但是，我稍后会尝试为这个特定案例设置一个环境，看看你的回答是否有帮助。

【参考方案2】：

rfc 中没有 499 http 代码。 Nginx 自己定义了 499 代码。

当客户端发送请求，并关闭连接而不等待 响应，出现 499 代码。如果你有很多 499 access_log，这主要是由缓慢的后端引起的（对你来说太慢了） 用户等待）。您可能需要优化您的网站性能。

http://forum.nginx.org/read.php?2,213789,213794#msg-213794

【讨论】：

后端其实没问题。 499 是由通过获取变量将数据转储到后端的机器人引起的。它发送请求并立即关闭连接而不等待响应。这是可以接受的行为。我只是不想因为它而扭曲崩溃。我现在正在使用 gunicorn，它非常适用于相同的用例。