[jboss-jira] [JBoss JIRA] Commented: (JBREM-953) CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException
Ron Sigal (JIRA)
jira-events at lists.jboss.org
Wed Apr 16 21:01:44 EDT 2008
[ http://jira.jboss.com/jira/browse/JBREM-953?page=comments#action_12409249 ]
Ron Sigal commented on JBREM-953:
---------------------------------
It turns out not to always be a good idea to continue after a SocketTimeoutException. In particular, once a java.io.ObjectInputStream throws a SocketTimeoutException, all subsequent reads will throw an EOFException. In this case it would be better immediately to close the ServerThread's socket and inform the client side that the connection is not usable. On the other hand, an org.jboss.serial.io.JBossObjectInputStream works as expected; i.e., it will continue to function after a SocketTimeoutException. In this case it is appropriate to keep the ServerThread in use.
Accordingly, org.jboss.remoting.transport.socket.ServerThread may now be configured, using key ServerThread.CONTINUE_AFTER_TIMEOUT (actual value "continueAfterTimeout"), to return itself to the threadpool (if set to "false") or continue processing (if set to "true"). If the key ServerThread.CONTINUE_AFTER_TIMEOUT is not used, then ServerThread will look to see if its SocketWrapper is using JBoss object streams, or not, and act accordingly.
Unit test: org.jboss.test.remoting.transport.socket.timeout.ServerThreadReuseAfterTimeoutTestCase.
Waiting for hudson results.
> CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException
> -----------------------------------------------------------------------------------
>
> Key: JBREM-953
> URL: http://jira.jboss.com/jira/browse/JBREM-953
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 2.4.0.CR1 (Pinto), 2.2.2.SP4
> Reporter: Ron Sigal
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.GA
>
>
> Currently, org.jboss.remoting.transport.socket.ServerThread will close its socket and return itself to the threadpool in the event of a SocketTimeoutException. However, it could simply continue trying to read the next invocation. The javadoc for java.net.Socket.setSoTimeout() states:
> Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid.
> If the timeout is due to transitory circumstances, then it would be much more efficient to allow the ServerThread to continue, rather than forcing the client to start over with a new socket.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list