Remy Maucherat wrote: > > Bill Barker wrote: > > > I don't remember anything like that for 3.3.x (and nothing even close is > > open in BZ). But, then again, I don't imagine that very many people > > try and > > use the Http10Connector in production, and Coyote is only available in the > > nightly for 3.3 until 3.3.2 comes out. > > > > o.a.t.u.net.PoolTcpEndpoint won't close the ServerSocket itself without > > shutting down. It looks like the root cause is from the JVM, nio, O/S, or > > some other place we can't see. > > (forwarding to tomcat-dev) > > Ok, I looked at it more, and the TCP endpoint code considers an > exception during accept a normal event:
Yes. This is correct - from memory, I think it can happen if the client disconnects mid-way through the TCP handshaking. Not entirely sure, though. Really, you have to look down at the system call level, see what the BSD socket interface defines on accept(2) - java rightfully doesn't really document this in the detail you need to determine what's going on. However, there are probably OTHER cases where an IOException (or other exception) from accept is a (fatal?) error. Unfortunately, java doesn't give any way to distinguish between these two cases. I suspect the best one can do is a highly platform-and-implementation-specific string comparison on the message in the exception. Nasty. > > OTOH, I don't think this should be the case, and I think we should > stop/start the server socket in that particular case, as was done in the > old HTTP connector: Though this is sometimes better (in the case when there's a real/fatal error), the much more common case is that it was just a straightforward client disconnect (at a particularly inconvenient point, admittedly). In this case, shutting down the server socket and reopening it is wrong for at least two major reasons: 1) Any other connections sitting in the socket accept queue are unceremoniously dropped. Legitimate client requests are lost. 2) In some cases, it won't be possible to reopen the socket. Consider a unix system that starts as root, binds to port 80, then drops privs. (It SHOULD be possible to work around this, by keeping the socket bound, but reopening it. The current code doesn't do this, and it's possible that java won't let you). If you can't distinguish between the fatal/normal cases (both of which are reported as IOException), there is NO WAY to do the correct thing - whichever way you do it will be wrong sometimes. Michael -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
