[
https://issues.apache.org/jira/browse/QPID-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu resolved QPID-2861.
------------------------------------
Resolution: Fixed
This issue is fixed. We handle this condition and prints a warning message.
> JMS client needs to handle duplicate commands replayed after failover
> ---------------------------------------------------------------------
>
> Key: QPID-2861
> URL: https://issues.apache.org/jira/browse/QPID-2861
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Critical
> Fix For: 0.7
>
>
> The c++ broker could resend commands after failover that is no longer valid
> on the client side.
> The commands maybe invalid (removed from the internal map) for two reasons,
> 1. These commands could have been acted on the client side but were unable to
> confirm to the broker before failover happened.
> 2. It could also that the c++ broker is actually sending commands that were
> already acked due to a bug on the broker side.
> So far I haven't been able to conclusively determine which of the above is
> causing the duplicate commands.
> Since this is only surfaced very recently I am speculating that it is the
> later as if it was the former then it would have been detected a lot earlier
> as the JMS client lacked any error handling in this area.
> It could also be that the broker is replaying only responses to certain
> commands like ExchangeQuery QueueQuery etc..
> These commands are sent by the JMS client only if the new addressing scheme
> is used, hence the reason why this issue can be reproduced only when the new
> addressing syntax is used.
> Irrespective of whether it's a broker bug or not the Java client should be
> able to handle this error.
> For example the c++ broker seems to resend an ExchangeQueryResult after
> failover, that had actually been sent to the client before failover. This
> causes a NPE on the JMS client which doesn't get handled properly and
> eventually kills the connection. This causes the client to retry the
> connection which in turn causes errors like Session already attached.
> Ex.
> 2010-09-16 17:16:05 error Channel exception: session-busy: Session already
> attached: [email protected]
> (qpid/broker/SessionManager.cpp:55)
> 2010-09-16 17:16:05 error Channel exception: not-attached: Channel 4 is not
> attached (qpid/amqp_0_10/SessionHandler.cpp:39)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
