uWSGI solleva OSError: errore di scrittura durante una richiesta estesa

Question

La mia applicazione utilizza nginx, con uWSGI sul lato server. Quando faccio una grande richiesta (con un tempo di risposta> 4s), appare la seguente:

SIGPIPE: writing to a closed pipe/socket/fd (probably the client 
    disconnected) on request _URL_ (ip XX.XX.XX.XX) !!! 

uwsgi_response_writev_headers_and_body_do(): Broken pipe 
    [core/writer.c line 287] during GET _URL_ (XX.XX.XX.XX) 

OSError: write error 

Sembra che uWSGI tenta di scrivere in un flusso, ma questo flusso è già stato chiuso. Quando controllo registro nginx (error.log):

upstream prematurely closed connection while reading response 
    header from upstream ... 

Naturalmente, il mio cliente (client REST o browser) riceve un errore 502.

Ricevo sempre questo errore dopo ~ 4 s.

Tuttavia, non so come prevenire questo problema. Ho cercato di impostare alcuni parametri nel mio file di configurazione di nginx:

location my_api_url { 
    [...] 
    uwsgi_buffer_size 32k; 
    uwsgi_buffers 8 32k; 
    uwsgi_busy_buffers_size 32k; 

    uwsgi_read_timeout 300; 
    uwsgi_send_timeout 300; 

    uwsgi_connect_timeout 60; 
} 

Ma la questione è ancora qui. Ho anche cercato di impostare questi parametri nel file di configurazione uWSGI (wsgi.ini):

buffer-size=8192 
ignore-sigpipe=true 
ignore-write-errors=true 

Prima di cercare di ottimizzare il tempo di risposta, spero che questo problema ha una soluzione. Non ne trovo uno che funzioni in un altro post. Lavoro con una grande quantità di dati, quindi il mio tempo di risposta, per alcuni casi, sarà tra 4-10 secondi.

Spero che mi può aiutare :)

Grazie mille in anticipo.

Answer 1

Può succedere che quando si caricano oggetti, si usi la codifica Chunked. C'è un'opzione uWSGI --chunked-input-timeout, che per default è di 4 secondi (è defaults al valore --socket-timeout, che è di 4 secondi).

Anche se il problema potrebbe teoricamente mentire da qualche altra parte, ti suggerisco di provare le opzioni sopra indicate. Inoltre, fastidiose eccezioni sono la ragione per cui ho

ignore-sigpipe=true 
ignore-write-errors=true 
disable-write-exception=true 

nel mio config uWSGI (notare che fornisco 3 opzioni, non 2): ignore-sigpipe fa uWSGI non mostrano errori SIGPIPE; ignore-write-errors non mostra errori con ad es. uwsgi_response_writev_headers_and_body_do; disable-write-exception impedisce la generazione di OSError nelle scritture.