You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/05/29 21:14:17 UTC
[jira] [Commented] (QPIDJMS-58) when a connection redirect error is
received, the original connection details will be used first
[ https://issues.apache.org/jira/browse/QPIDJMS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565238#comment-14565238 ]
ASF subversion and git services commented on QPIDJMS-58:
--------------------------------------------------------
Commit 07d1637d959002cef9c7eb5466f0185618db29bc in qpid-jms's branch refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=07d1637 ]
https://issues.apache.org/jira/browse/QPIDJMS-58
https://issues.apache.org/jira/browse/QPIDJMS-59
https://issues.apache.org/jira/browse/QPIDJMS-60
URI Pool updated to provide thread safe operations. Added method
addFirst and used that to ensure that redirect URIs are always used on
the next connect attempt. Updated the remove method to use the same
logic as add to find the matching URI to remove.
> when a connection redirect error is received, the original connection details will be used first
> ------------------------------------------------------------------------------------------------
>
> Key: QPIDJMS-58
> URL: https://issues.apache.org/jira/browse/QPIDJMS-58
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.2.0
> Reporter: Robbie Gemmell
> Assignee: Timothy Bish
> Fix For: 0.3.0
>
>
> When the client is using the failover layer and receives a connection redirect error from the peer, it will try to reconnect to the same connection details first before using the newly added uri details on subsequent reconnect attempts.
> I noticed this due to FailoverRedirectTest#testFailoverHandlesRemotelyEndConnectionWithRedirection failing because the connection to the 'backup peer' was never completed after it was redirected by the 'rejecting peer'. The logs show that the second attempt was being made to the 'rejecting peer' and never completed. That is presumably because the test peer is only capable of ever accepting a single connection, but doesnt unbind the server socket after doing so and instead only does so when the peer is shut down or the client socket read loop exits.
> The test presumably passes typically because the the test peer usually wins race to close the server socket before the next connect attempt is made, leading it to fail and cause the client to try the next URI, the details given by the original redirect error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org