[QPID-7394] [0-8..0-91] Prefetch accounting incorrect when session rolled back / recovered

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.32, qpid-java-6.0, qpid-java-6.0.4
• Fix Version/s: qpid-java-6.0.5, qpid-java-6.1
• Component/s: JMS AMQP 0-x
• Assignee: Unassigned
• Reporter: Keith Wall
• Created: 12/Aug/16 13:25
• Updated: 02/Oct/19 19:22
• Resolved: 12/Sep/16 12:47

Description

When the application calls Session#receive(), the client will automatically open the prefetch window by 1 message if necessary (QPID-6088). On committing the received message, the client takes care to revert the prefetch level back to the session's default value. However, if the application calls rollback, the client fails to account for the increased credit, so when the application calls #receive again, the prefetch window will be opened further.

If the downstream application experiences some kind of failure meaning it rolls back every message, this could potentially lead to the prefetch buffer growing large. If the queue is deep, this could cause excessive network utilisation (as large numbers of messages are continually received/rejected) and excessive memory use on the client.

This defect also allows a Broker defect to manifest - QPID-7387.

Issue Links

• relates to: QPID-7387 [Java Broker, AMQP 0-8..0-91] Correct handling of consumer credit
• relates to: QPID-6088 [Java Client] AMQP 0-8/8/9-1 prefetch should auto expand when receive is called in a situation where the prefetch buffer is full