On 23/09/2013 00:54, Rainer Jung wrote: > I agree that there's probably another problem further up the stack.
I'm looking at this now. > Since the apr endpoint explicitely uses the return value of remove to > decide whether something was removed, APT_NOTFOUND seems better. But as > you said: why is it calling remove for a socket not in the poller? When > the endpoint called remove for "2856392", the poller has size one and > consisted only of socket 2218784. Strange. I suspect that this is because the socket could be in the poller for write while being processed for read (or the other way around). If the IO operation fails, the socket needs to be removed from the poller otherwise other bad things (tm) happen. This is one of the complications caused by having to implement some WebSocket writes as blocking. <snip/> > - since removeFromPoller() is part of error condition handling, and its > return code is used to determine adjusting the externally tracked size > of the poller and the connection counts, the return code must be > "correct". It is still open to me, whether returning APR_NOTFOUND is a > problem for the conection count tracking. I was expecting a APR_NOTFOUND return value if the socket wasn't in the Poller when I wrote that code. > - we should check, whethera 0 byte read after OPEN_READ really is a > problem or must be expected even for a non-broken socket. OPEN_READ should mean there is data available to read without bocking. Therefore, a read returning 0 bytes looks like an error to me. Could it be signalling EOF ? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
