[
https://issues.apache.org/jira/browse/QPID-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131977#comment-13131977
]
Robbie Gemmell commented on QPID-3532:
--------------------------------------
I do feel this is a reasonable improvement over what we have, considering
failover was previously allowed to proceed concurrently with the client in any
old state and as per the QueueBrowser tests could often allow completely
incorrect behaviour as a result. Most of the operations the client does already
do hold the failover mutex (ironically enough its mainly only 0-10 failover
that didnt), so there shouldnt be much performance difference in these changes
as there are basically only a few if statements in there now which werent there
already.
As I say, I'm not overly bothered whether this makes into 0.14 or not. That
said, since this is only the alpha deadline, its at best 6 weeks until 0.14
ships (assuming we arent a month late like the last couple releases were), a
month before an RC is due, and these changes are somewhat tiny and easily
revertable, I wouldnt feel at all concerned about putting them in now even
supposing we did have to take them out again in the next few weeks.
> Fix the blocking of JMS operations when failover happens
> --------------------------------------------------------
>
> Key: QPID-3532
> URL: https://issues.apache.org/jira/browse/QPID-3532
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Reporter: Alex Rudyy
> Assignee: Alex Rudyy
> Fix For: 0.13
>
> Attachments:
> QPID-3532-make-the-0-10-client-hold-the-failover-mutex-during-failover.patch
>
>
> When connection is lost and failover is started the Qpid Client should block
> on invocation of JMS operations which require sending or receiving data over
> the network.
> With current implementation the performing of certain operations during
> failover can lead to unexpected behaviour.
> For example, closing QueueBrowsers during failover has been observed to cause
> issues because it is possible to send the old subscription destination in a
> cancel command to the new broker as the close and failover are allowed to
> progress concurrently. As result of it the broker might close the session
> with a NOT_FOUND execution exception because failover has not finished queue
> re-creation on a new broker
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
