[jboss-jira] [JBoss JIRA] Commented: (JBREM-690) Once the socket of a callback server timeouts, it starts to silently discard traffic

[Ron Sigal (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-690?page=comments#action_12352252 ] 
            
Ron Sigal commented on JBREM-690:
---------------------------------

All communication in Remoting is initiated by the client (in the functional sense - it could be a callback client).  The server never sends bytes except in response to the client.  Based on that fact, I've been playing with a "lite" connection checking idea.  When the ServerSocketWrapper closes, it writes a CLOSING byte just before it closes.  ClientSocketWrapper gets a new checkOpenConnection() method which looks for getInputStream.available() > 0, which would only be true if the ServerSocketWrapper wrote a CLOSING byte.  SocketClientInvoker.getPooledConnection() uses this method to test if a pooled socket's remote endpoint has closed, and, if so, discards it.  So this isn't a full-fledged, expensive connection check, but it works to avoid reusing a socket when the server's socket has timed out.

More particularly, the following changes have been made: 

1. There's a new interface org.jboss.remoting.transport.socket.OpenConnectionChecker, with the method checkOpenConnection().  ClientSocketWrapper now implements OpenConnectionChecker, and ClientSocketWrapper.checkOpenConnection() throws an IOException if it finds a byte available on the input stream.

2. ServerSocketWrapper overrides SocketWrapper.close() and writes a CLOSING byte when it is called.

3. MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() check if a socket wrapper implements OpenConnectionChecker, and if it does, calls checkOpenConnection.  They do this automatically, whether or not connection checking is turned on.  If checkOpenConnection() throws an exception, the socket wrapper is discarded.

4 The code to close the socket's input and output streams (which is probably not necessary but couldn't hurt) has been moved from ServerThread to SocketWrapper.close().  This has been done so that the output stream is still open for ServerSocketWrapper.close() to write its CLOSING byte.

> Once the socket of a callback server timeouts, it starts to silently discard traffic
> ------------------------------------------------------------------------------------
>
>                 Key: JBREM-690
>                 URL: http://jira.jboss.com/jira/browse/JBREM-690
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.2.0.Alpha6
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 2.2.0.Alpha7
>
>
> Please write the following test (and I actually mean it, please do, and keep it your test suite):
> Create a "socket" transport client and register a listener to it, so the push callback server is initialized.
> Send a callback to the client, to make sure a socket is created and traffic is sent over it.
> Wait enough for the callback socket to timeout (a little bit longer than ServerInvoker.DEFAULT_TIMEOUT_PERIOD).
> Send a new callback to the client.
> The callback will be silently discarded, never to be heard of again. 
> For the Messaging version of this bug, please see http://jira.jboss.org/jira/browse/JBMESSAGING-371 and the associated RemotingTest.test testMessageListenerTimeout()

-- 
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