[jboss-jira] [JBoss JIRA] Commented: (JBREM-745) client unable to send if server recycles

[Ron Sigal (JIRA)]

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

Here's is what's happening:

org.jboss.remoting.MicroRemoteClientInvoker maintains a pool of connections to the server, where each connection corresponds on the server side to an org.jboss.remoting.transport.socket.ServerThread, which responds to invocation requests sent over the connection.  When the first Connector shuts down, the corresponding org.jboss.remoting.transport.SocketServerInvoker calls ServerThread.shutdown() on all of its ServerThreads, but they may not shut down immediately if they are waiting on a read() call.  When Client.invoke() is called after the second Connector is started, it may (and in this example does) have a pooled connection to an old ServerThread, and the invocation ends up going to the old SocketServerInvoker.  The SocketServerInvoker throws a ServerInvoker$InvalidStateException which is rethrown on the client side.

Exactly the same sequence of events occurs with Remoting 2.0.0, except that InvalidStateException was not serializable in 2.0.0 (see JBREM-613), so the attempt to send it back to the client fails.  As a result, the old ServerThread shuts itself down, and the MicroSocketClientInvoker hits an end of file and creates a new connection to the new Connector, with which it successfully completes the invocation.  Therefore, the InvalidStateException is invisible with Remoting 2.0.0, and it is detected with 2.2.0.

A simple workaround is just to put Client.invoke() in a try/catch block that catches the InvalidStateException and calls Client.invoke() again.  

However, Remoting should at least make an attempt to handle this situation quietly under the covers so that the InvalidStateException doesn't make it back to the application code.  For example, if MicroSocketClientInvoker gets an InvalidStateException, it could retry the invocation with a new connection.  Or perhaps the problem can be handled on the server side to avoid the round trip (John Mazzitelli's suggestion).





> client unable to send if server recycles
> ----------------------------------------
>
>                 Key: JBREM-745
>                 URL: http://jira.jboss.com/jira/browse/JBREM-745
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4
>            Reporter: John Mazzitelli
>         Assigned To: Ron Sigal
>         Attachments: RemotingTest.java
>
>
> I have TestNG unit test that fails about 75% of the time.  See attached.
> The issue here is that if a server shuts down and then restarts, the client will fail to be able to send a message to it.
> Replication works like this:
> 1. create and start a connector
> 2. create and connect a client
> 3. send a message to the server and see that it works (which creates a ServerThread worker thread on server side)
> 4. stop connector and the re-start it
> 5. send a message to the server and see that it FAILS due to:
> org.jboss.remoting.ServerInvoker$InvalidStateException: Can not process invocation request since is not in started state.
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:745)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
> 	at org.jboss.remoting.Client.invoke(Client.java:1550)
> 	at org.jboss.remoting.Client.invoke(Client.java:530)
> 	at org.jboss.remoting.Client.invoke(Client.java:518)

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