| Summary: | stopping a connector produces intermittent SocketException | ||
|---|---|---|---|
| Product: | Tomcat 6 | Reporter: | Paul McMahan <paulmcmahan> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 6.0.7 | ||
| Target Milestone: | default | ||
| Hardware: | All | ||
| OS: | Mac OS X 10.4 | ||
| Attachments: | patch avoids logging SocketException when endpoint has been stopped | ||
Created attachment 19501 [details] patch avoids logging SocketException when endpoint has been stopped patch created against https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk Fixed in 6.0.11. I am changing status from VERIFIED to CLOSED. |
Geronimo embeds tomcat by wrappering org.apache.catalina.startup.Embedded as a gbean. Geronimo stops an http connector by calling the stop() method of org.apache.catalina.connector.Connector. Depending on the current state of the connector when it is stopped, the socket connected to it can throw the following exception: Feb 2, 2007 2:20:05 PM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed java.net.SocketException: Socket closed at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:450) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310) at java.lang.Thread.run(Thread.java:613) This behavior is intermittent but occurs frequently in the unit test cases for Geronimo's tomcat gbean and when the Geronimo server is shut down. The exception occurs when the socket opened by JIoEndpoint.Acceptor.run() is closed by JIoEndpoint.unlockAccept(). In that case it seems that the SocketException should be ignored. Checking to see if the JIoEndpoint is actually running before logging the error is one way to avoid this problem. I will attach a patch for that approach shortly.