qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPIDJMS-58) when a connection redirect error is received, the original connection details will be used first
Date Fri, 29 May 2015 19:14:17 GMT

    [ 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
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=07d1637 ]


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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message