Il giorno 13/dic/2010, alle ore 17.41, [email protected] ha scritto: > Hello Roberto, > > with bigger timeout I'am getting much less so errors (but still get) > > read, write, exc = m.fdset() > if read: > yield uwsgi.wait_fd_read(read[0], 1) > elif write: > yield uwsgi.wait_fd_write(write[0], 1) > > so if I'll change it to > > read, write, exc = m.fdset() > if read: > yield uwsgi.wait_fd_read(read[0], 10) > elif write: > yield uwsgi.wait_fd_write(write[0], 10) > > I will get much less so errors > > __
Ok, we can assume that you have reached the maxium performance for your hardware (related to timeout), or the http server you are connecting to is rejecting after N connection. This is not important but uWSGI must manage this conditions better (and safely). Somewhere in the epoll adapter there must be a bug that set a file descriptor as "waiting for read" even if it is not connected. I can reproduce your error at 100% so it must not be difficult to fix it. In the kqueue adapter (tested with OSX and FreeBSD) there is no error (even with higher values) so this should be even easier to find and fix -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
