Yup, we're indeed using HTTP sockets, it's easier to debug and last time we tried using the uwsgi protocol, it also suffered from the graceful = recv() error issue. The app behind uwsgi is so heavy that any header parsing overhead is irrelevant, so we just kept using HTTP.
On v1.3, the http-socket commands were just socket, reload-mercy was not set and buffer-size used to be 65536. I've also tried sending the master a SIGHUP manually instead of touching the uwsgi ini / touch-reload file, but it generates the same recv() error in Nginx. Here's a lightly censored version, replaced app name with "xxx", I've sent a link to the full file in a separate email: [uwsgi] http-socket = 0.0.0.0:7654 http-socket = 0.0.0.0:7655 http-socket = 0.0.0.0:7656 stats = 0.0.0.0:7554 listen = 1000 protocol = http env = DJANGO_SETTINGS_MODULE=xxx.settings virtualenv = /var/python/xxx chdir = /var/python/xxx/src/xxx pythonpath = /var/python/xxx/src module = django.core.handlers.wsgi:WSGIHandler() touch-reload = /var/python/xxx/django.wsgi reload-mercy = 30 processes = 25 buffer-size = 65535 enable-threads = true max-requests = 5000 uid = www-data gid = www-data On 20 June 2013 15:02, Roberto De Ioris <[email protected]> wrote: > > > Hi Roberto, > > > > Whoa, that's quick, thanks! I thought I saw the value 65536 in the docs > > before and just used it in the configuration file, it's kinda funny that > > it > > started complaining after an upgrade from 1.3 to 1.9.x on the same config > > file. > > > > > > I've also checked if the old/existing "issue" with graceful reloading is > > fixed by chance, but nope, on our system (still Ubuntu 8.04 LTS, to be > > decommissioned soon) a graceful reload still causes Nginx frontend to > > complain about recv() errors, connection reset by peer. Uwsgi logs a > > graceful restart and all seems well on that end, but somehow, TCP RST are > > still being sent over the wire or something. Lets see if I can reproduce > > it > > with a minimal wsgi app, a single connection and wireshark. > > > > > > Kind regards, > > > > Chi Ho Kwok > > > > > Can you paste your config ? last time a user complained about that he was > using --http > > > > > On 20 June 2013 06:18, Roberto De Ioris <[email protected]> wrote: > > > >> > >> > Hi there, > >> > > >> > While debugging a weird issue with listen queue being full, I tried > >> > upgrading to the latest version and it kinda broke the site in a > >> > mysterious > >> > way, with lines in the error log saying: > >> > > >> > invalid HTTP request size (max 0)...skip > >> > > >> > This was caused by setting "buffer-size = 65536", lowering it by one > >> byte > >> > solved the issue. > >> > > >> > > >> > Logged as https://github.com/unbit/uwsgi/issues/324, posting here too > >> so > >> > Google can find it easier, as searching for the log message resulted > >> in > >> > nothing but a grep on the source code pointed me directly to the right > >> > config variable. > >> > > >> > proto/http.c > >> > 225: uwsgi_log("invalid HTTP request size (max > >> %u)...skip\n", > >> > uwsgi.buffer_size); > >> > > >> > > >> > > >> > Kind regards, > >> > > >> > Chi Ho Kwok > >> > > >> > >> Internally the buffer size is 16bit. I have added a check to force it to > >> 65535 when higher values are specified > >> > >> > >> -- > >> Roberto De Ioris > >> http://unbit.it > >> _______________________________________________ > >> uWSGI mailing list > >> [email protected] > >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > >> > > _______________________________________________ > > uWSGI mailing list > > [email protected] > > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
