uWSGI和优雅地杀死一个多线程的Flask应用程序

我正在实现一个使用APScheduler（它使用线程池）来获取一些资源的系统。uWSGI和优雅地杀死一个多线程的Flask应用程序

我想找出一种方法来检测“应用程序重新启动”，以便我将能够关闭APScheduler线程池。我正在通过向uWSGI主进程发送SIGHUP来重新启动。

有没有人尝试过其中之一？如果是这样，检测应用程序重新启动事件的正确方法是什么？

uwsgidecorators有postfork装饰，
uwsgi模块signal_wait和signal_received功能

signal_wait功能块，所以我的线程运行，但uWSGI不服务请求。我也尝试将scheduler.daemonic设置为False和True - 这对两种方式都没有帮助。该uWSGI进程仍然记录是这样的：

worker 1 (pid: 20082) is taking too much time to die...NO MERCY !!!

来源

2013-01-08 sederek

我试图找出一种方法来检测“应用启动”这样我就可以关闭APScheduler线程池。

我觉得没有简单的方法来可靠地检测应用程序重启，但uwsgi可以重新加载后执行代码或关闭，在以下方面：

1）代码将在单独的进程中执行：添加钩为用户-atexit对您uwsgi配置：

012：

[uwsgi] 
... 
hook-as-user-atexit = exec:python finalization.py

2）将在其中一名工人被调用

3）在这种情况下，您应该重新加载touch uwsgi.pid。将其中一名工人被调用，只有重装后：

[uwsgi] 
... 
pidfile = ./uwsgi.pid 
touch-reload = ./uwsgi.pid

Python代码：

import uwsgi 

def will_executed_after_reload(*args): 
    print("I was invoked") 

uwsgi.register_signal(17, "worker", will_executed_after_reload) 
uwsgi.add_file_monitor(17, "./uwsgi.pid")

来源

2017-03-08 18:33:12

uWSGI和优雅地杀死一个多线程的Flask应用程序

回答

相关问题