[
http://jira.jboss.com/jira/browse/JBREM-534?page=all ]
Ron Sigal closed JBREM-534.
---------------------------
Resolution: Done
The code changes have already been described in a previous comment.
The unit test introduced for this issue had some failures because the client invoker was
getting a stale thread from the connection pool, in the case that connection checking is
turned off. It seems reasonable, however, that if the user turns off connection checking,
then the application code should be responsible for handling this problem. The unit test
was changed to make to attempts to call Client.invoke(), so that if the first attempt
failed due to a stale thread, the second call will lead to the creation of a new
connection to a new Connector.
multiplex client cannot re-connect to server after it has died and
then been re-started
---------------------------------------------------------------------------------------
Key: JBREM-534
URL:
http://jira.jboss.com/jira/browse/JBREM-534
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: transport-multiplex
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: Tom Elrod
Assigned To: Ron Sigal
Fix For: 2.0.0.CR1 (Boon)
"However, I have found another issue that still needs looking into. If using
multiplex transport and a server is killed and then re-started, it looks like the detector
sees the server restarting, then tries to ping it, but can not, so discards it as being
dead, then repeats this process. This does not happen when using socket transport, so
looks like there is some issue where multiplex client is having trouble making invocations
on a server after it has gone down and then come back up."
--
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