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應用程序

回答

相關問題