[ http://jira.jboss.com/jira/browse/JBREM-745?page=comments#action_12362189 ] John Mazzitelli commented on JBREM-745: --------------------------------------- BTW: my tests that did this kind of thing all worked on 2.0.0.GA. I only started seeing this bug when moving to JbossAS 4.2.GA which has remoting 2.2.0.SP4 in it. -- 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

[ 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). -- 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

[ http://jira.jboss.com/jira/browse/JBREM-745?page=all ] Ron Sigal closed JBREM-745. --------------------------- Resolution: Done The tests are passing on cruisecontrol, with the exception of occasional timeouts due to a short timeout configuration. The timeout value in the tests has been extended. -- 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