[QPID-2876] Design issues in Java client failover

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.7
• Component/s: JMS AMQP 0-x
• Assignee: Rajith Muditha Attapattu
• Reporter: Rajith Muditha Attapattu
• Created: 21/Sep/10 02:01
• Updated: 14/Mar/17 20:07
• Resolved: 18/Oct/10 21:56

Description

The java client keeps AMQP commands in it's replay buffer in case it needs to replay them during failover.
However this could cause several issues. For example,

1. The failover code at the JMS layer recreates subscriptions after failing over to a new node. However if there were message subscriptions present in the replay buffer and were replayed after failing over it can cause the subscription attempt by the JMS layer to fail if using exclusive subscriptions.

2. If there were ExchangeQuery/QueueQuery (or any command that expects a response) gets replayed, it will cause the broker to respond, but the JMS client may not have the command in it's internal map that manages request-response coordination. This can cause errors. See QPID-2861

Since we are not implementing full session resume for the 0-10 client, I don't think there is any advantage in replaying anything other than the message transfers.
The JMS client should also attempt to shrink it's in doubt window by periodically calling flush to get the broker to confirm the completion of the commands.
This will prevent in message being duplicated unnecessarily.

There maybe a potential bug where the Java client may not be removing commands even after the broker confirming them. I will create a new JIRA if this is confirmed.