2012-05-01 14 views
8

Tengo aplicaciones de Facebook con matraz con nginx y uwsgi. Cuando se reciben post de Facebook, que siempre tiene un error:Error: readv() error (104: Restablecimiento de la conexión por pares) mientras lee en sentido ascendente

readv() failed (104: Connection reset by peer) while reading upstream 

Pero cuando accedo a mis aplicaciones directamente (con el método GET), que transcurrió sin problemas. Lo que hice:

  1. Límite @ app.route con POST método solamente - no funciona.
  2. Agregar límite en wsgi: uwsgi_buffer_size (en caso de que la solicitud de facebook sea grande), y uwsgi_harakiri (en caso de que uwsgi proporcione tiempo de espera antes de finalizar la solicitud) - no funcione.

Tengo una solución alternativa en django pero todavía no sé cómo implementarla en el matraz. ¿Alguien podría ayudar, por favor?

+0

la respuesta es un poco ridículo para mí. Tengo que procesar todos los datos de la publicación, incluso si mi proceso no está haciendo nada. si "nada" no está en request.form: pass. Su funcionamiento ... Por cierto, Facebook abre la aplicación con solicitud POST, así que debería agregar eso para cada ruta. Debe haber una mejor manera de hacerlo ... – asofyan

+0

Si hay datos en un socket, debe leerlos (no hay otras opciones). En la wiki de matraz, puede encontrar un middleware para eludir este problema común en la configuración de proxy: http://flask.pocoo.org/snippets/47/ uWSGI puede ayudarlo con la opción --post-buffering, pero es solo una atajo, nada mágico en él. – roberto

+0

Gracias por el snippet @roberto – asofyan

Respuesta

2

Este es el error de uwsgi. Puede obtener más de [uWSGI] Several bugs.

La solución simple es que debe leer el cuerpo POST mediante wsgi.input, incluso si el cuerpo POST es nulo o no necesita los parámetros POST.

+0

esto no tiene nada que ver con uWSGI (y ciertamente no es un error). Cerrar un socket sin leer datos en él, es un comportamiento de programación incorrecto. uWSGI puede ayudarlo (si no quiere cambiar su código) al almacenar datos de correos automáticamente a través de la opción --post-buffering. – roberto

+0

@roberto Gracias. Cuando agrega la opción post-buffering en la configuración uwsgi, funciona. Pero en algunos casos, por ejemplo, la solicitud posterior no tiene parámetros, no es necesario leer el cuerpo de la publicación desde wsgi.input. Entonces, no creo que sea el error de los programadores. –

0

El problema es que "en sentido ascendente" (el proceso real que nginx está aproximando) está cerrando la conexión.

En mi caso, Django es mi servidor web y necesitaba establecer DATA_UPLOAD_MAX_NUMBER_FIELDS para que fuera más grande porque había demasiados campos en la solicitud POST.

Cuestiones relacionadas