As a workaround I now set devpoll_events to 1. This fixes the issue, though it might slightly impact the performance. Nevertheless, if someone can point me to a clean way to fix this, I'd give it a try.
-Arne On 02/16/2015 03:46 PM, Arne Jansen wrote: > Hi, > > I suspect a bug in the devpoll implementation. What I see is this: > > recv() failed (134: Transport endpoint is not connected) while reading > response > header from upstream > > truss (solaris) tells me that nginx has done a connect() = EINPROGRESS, > directly > followed by a read() on that socket, getting the ENOTCONN error. > > What I suspect is as follows: > I have two fds waiting for an event. Both get ready at the same time. > ngx_devpoll_process_events fetches both from the kernel. While handling the > first event, the second fd gets closed, reopened and connected (with > EINPROGRESS). Afterwards, ngx_devpoll_process_events handles the already > received event for the other fd. This leads to a read() call even though the > socket is not connected yet. > What I'm missing is code in ngx_devpoll_del_event that deletes revents from > the global event_list, but I'm not sure if that's the right way to approach > this and how it is supposed to synchronize with ngx_devpoll_process_events. > > Thanks, > Arne _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
