Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
-
None
Description
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: guest@QPID.b39ab79e-3df8-468a-96ce-9c38f469a551 (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)