2013-01-08 4 views
7

Sto implementando un sistema che utilizza APScheduler (che utilizza il pool di thread) per recuperare alcune risorse.uWSGI e abbreviare con grazia un'applicazione multithreaded Flask

Sto cercando di capire un modo per rilevare il "riavvio dell'app" in modo che sia possibile interrompere il pool di thread APScheduler. Sto riavviando inviando SIGHUP al processo master di uWSGI.

Qualcuno ha provato uno di questi prima? In tal caso, qual è il modo corretto per rilevare un evento di riavvio dell'app?

  • uwsgidecorators ha postfork decoratore, modulo
  • uwsgi ha signal_wait e signal_received funzioni

signal_wait blocchi funzione così i miei fili corrono ma uWSGI non serve richieste. Ho anche provato a impostare scheduler.daemonic su False e True - non aiuta in alcun modo. Il processo uWSGI registra ancora qualcosa di simile:

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

risposta

1

Sto cercando di capire un modo per rilevare "restart app" in modo che sarò in grado di arrestare pool di thread APScheduler.

Penso che non ci sia modo semplice per rilevare certamente app restart, ma uwsgi può eseguire codice dopo ricarica o spegnere, in questi modi:

1) codice verrà eseguito nel processo separato: aggiungi hook-as-user-atexit alla propria configurazione uwsgi:

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

2) verrà richiamato in uno dei lavoratori:

import uwsgi 

def will_invoked_after_reload_or_shutdown(): 
    print("I was invoked") 

uwsgi.atexit = will_invoked_after_reload_or_shutdown 

3) In questo caso, è necessario ricaricare tramite touch uwsgi.pid. Verrà richiamato in uno dei lavoratori, solo dopo ricarica: codice

[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")