[Python] Deploy con nginx e proxy_pass

[Manlio Perillo]

On 03/01/2014 18:42, Alessandro Dentella wrote:
> On Fri, Jan 03, 2014 at 12:45:02PM +0100, Manlio Perillo wrote:
>> On 03/01/2014 12:34, Alessandro Dentella wrote:
>>> [...]
>>> La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che usa
>>> time.sleep()
>>>
>>>     class IsUp(tornado.web.RequestHandler):
>>>         def get(self):
>>>             self.write("Is Up Porta %d" ...)
>>>     	self.finish()
>>>
>>>     class Blocking(tornado.web.RequestHandler):
>>>         def get(self, numero=10):
>>>             time.sleep(int(numero))
>>>     	self.write("Bloccato Porta %s\n" % options.port)
>>>     	self.finish()
>>>
>>> la chiamata usando 'wget -q -O - http://ngtest/blocking/30/' ed
>>> interrompendolo con Control-c.
>>
>> Ok.
>> Ma quante instanze di tornado hai attive?
>
> 10 al momento, vedi descrizione qui [1]
>

Allora, vediamo se ho capito.

Hai scritto che:

 > la chiamata usando 'wget -q -O - http://ngtest/blocking/30/' ed
 > interrompendolo con Control-c.
 > In un terminale separato in ciclo di
 >    'wget -q -O - http://ngtest/is_up'
 > Il ciclo si blocca nel momento della interruzione e riprende solo
 > quando termita il tempo (e quindi il processo si libera)

Quindi quello che fai è prima richiedere http://ngtest/blocking/30/, in 
modo che una delle instanze di tornado si blocchi per 30 secondi, e poi 
un serie di richieste normali per vedere se le altre instanze rispondono.

Quello che succede è che in condizioni normali, ottieni subito una 
risposta instantanea, ma non appena termini in modo brusco la prima 
richiesta, Nginx considera quella instanza libera e quindi una delle 
richieste normali blocca.


Secondo me il problema è quello che ti ha indicato Roberto.
La tua instanza di tornado è bloccata dalla sleep, ma continua ad 
accettare connessioni a causa della backlog nella listen.

Vedi:
http://stackoverflow.com/questions/5111040/listen-ignores-the-backlog-argument

Se usi Linux quindi direi che hai un bel problema.

> [...]

> Come già detto in altra mail, il problema residuo sorge quando una chiamata
> viene interrotta. Nginx libera subito la risorsa e passa una nuova chiamata
> a quel processo che in realtà è ancora occupato.
>

E' occupato, ma continua ad accettare connessioni da parte di Nginx.

Mi vengono in mente un paio di soluzioni brusche, ma dipende da come 
gestisci questa situazione nel caso "reale".

Nel test che hai fatto, interrompevi la connessione manualmente.
Nel caso reale cosa succede?

Da quello che scrivi mi sembra di capire che la connessione venga 
interrotta bruscamente.  Ma in che modo?

Ad esempio, per "risolvere" il problema, puoi terminare e poi riavviare 
il processo nel caso in cui una connessione con Nginx viene interrotta 
prima che la richiesta HTTP termini normalmente.  Non so se è possibile 
nel tuo caso, dovrei fare dei test.


Ciao  Manlio