[jira] Resolved: (WSCOMMONS-402) SimpleHttpServer doesn't shut down cleanly on some platforms

["Davanum Srinivas (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSCOMMONS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas resolved WSCOMMONS-402.
----------------------------------------

    Resolution: Fixed

applied fix from David. Many thanks Andreas

-- dims

> SimpleHttpServer doesn't shut down cleanly on some platforms
> ------------------------------------------------------------
>
>                 Key: WSCOMMONS-402
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-402
>             Project: WS-Commons
>          Issue Type: Bug
>         Environment: minotaur.apache.org: Java HotSpot(TM) 64-Bit Server VM (build diablo-1.5.0_07-b01, mixed mode)
>            Reporter: Andreas Veithen
>            Priority: Minor
>
> Different JVM implementations show different behaviors when Thread#interrupt is called on a thread that is blocked in ServerSocket#accept:
> 1. Most JVMs only set the interrupted flag on the thread but don't trigger an exception.
> 2. Other JVMs cause a java.io.InterruptedIOException to be thrown out of ServerSocket#accept but don't set the interrupted flag.
> On JVMs that have behavior 1, when calling SimpleHttpServer#destroy, the sequence of events is as follows:
> 1. SimpleHttpServer#destroy calls ExecutorServide#shutdownNow.
> 2. ExecutorServide#shutdownNow calls Thread#interrupted on the thread running DefaultConnectionListener (and blocked in ServerSocket#accept). This sets the interrupted flag, but doesn't cause an exception.
> 3. SimpleHttpServer#destroy calls ExecutorServide#awaitTermination which will only return after the specified timeout (because the DefaultConnectionListener thread is still running).
> 4. SimpleHttpServer#destroy calls DefaultConnectionListener#destroy which closes the ServerSocket.
> 5. ServerSocket#accept throws an exception. The catch block in DefaultConnectionListener#run checks the interrupted flag and since it is set, the method exits, terminating the thread.
> Except for step 3, this approach is correct and results in a clean shutdown.
> On JVMs having the other behavior, the sequence of events is completely different:
> 1. SimpleHttpServer#destroy calls ExecutorServide#shutdownNow.
> 2. ExecutorServide#shutdownNow calls Thread#interrupted on the thread running DefaultConnectionListener (and blocked in ServerSocket#accept).
> 3. An InterruptedIOException is thrown out of ServerSocket#accept. Since the interrupted flag is not set, the exception is handed over to the DefaultConnectionListenerFailureHandler.
> 4. DefaultConnectionListenerFailureHandler#failed returns true and DefaultConnectionListener will immediately reenter ServerSocket#accept.
> 5. SimpleHttpServer#destroy calls ExecutorServide#awaitTermination which will only return after the specified timeout (because the DefaultConnectionListener thread is still running).
> 6. SimpleHttpServer#destroy calls DefaultConnectionListener#destroy which closes the ServerSocket.
> 7. ServerSocket#accept throws an exception. Since the interrupted flag is still not set, the exception is again handed over to DefaultConnectionListenerFailureHandler#failed which instructs the DefaultConnectionListener to retry.
> 8. Since the original server socket is now closed, DefaultConnectionListener#run will create a new ServerSocket and open the port again. It then blocks in ServerSocket#accept.
> 9. SimpleHttpServer#destroy shuts down the request processors and exits.
> As can be seen this leaves the HTTP port open and SimpleHttpServer doesn't shut down cleanly.
> The problem can be reproduced by running the transport tests on minotaur (peope.apache.org). The HTTP tests will fail with an "Address already in use" error because at some point a test case tries to start a different HTTP server on the port that is still used by the SimpleHttpServer instance that didn't shut down cleanly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.