[QPID-7505] [JMS AMQP 0-x Client] [AMQP 0-10] Synchronous #receive(long) might return null even though there are messages on the queue and client has enough credit

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.18, 0.20, 0.22, 0.24, 0.26, 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
• Fix Version/s: qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-client-0-x-6.3.0
• Component/s: JMS AMQP 0-x
• Assignee: Keith Wall
• Reporter: Alex Rudyy
• Created: 10/Nov/16 10:23
• Updated: 08/Jun/17 13:06
• Resolved: 10/Nov/16 16:47

Description

As part of changes made for QPID-1642 the functionality of BasicMessageConsumer_0_10#receive(long) was changed to force message delivery by sending message.flush when there is no message present locally in a consumer queue. The message.flush is followed by the message.flow to restore the credit as message.flush forces the broker to exhaust its credit supply making it zero when message.flush command completes. However, no sync is sent after sending message flow. As result, in some cases the credit is not restored promptly impacting various messaging scenarios when message is published immediately after receive() is called but the published message is delivered to another consumer because credits are not restored after message.flush

This problem was detected by the sporadic failure of ConsumerPriorityTest on the 0-10 path.

Issue Links

• is related to: QPID-7699 ConsumerPriorityTest#testLowPriorityConsumerDoesNotReceiveMessagesIfHigherPriorityConsumerAvailable occasionally fails on 0-10 path