[QPID-3616] Java Broker misinterprets message.flow infinite credit value (0xFFFFFFFF)

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.13
• Component/s: Broker-J
• Assignee: Unassigned
• Reporter: Keith Wall
• Created: 15/Nov/11 10:02
• Updated: 09/Jul/19 17:06
• Resolved: 09/Jul/19 17:06

Description

The AMQP 0-10 defines 0xFFFFFFFF as meaning "an infinite amount of credit." as the value argument to the message.flow command.

A bug in the Java Broker (WindowCreditManager) means that this value is interpreted literally. The WCM class should be changed to understand the special value.

It also appears that notification logic in WindowCreditManager#restoreCredit presently relies on this defect. This must be refactored during this change. SubscriptionImpl and Subscription_0_10 appears to contain further workarounds in #creditStateChanged() callback methods. These should be reworked too.

if(_state.compareAndSet(State.SUSPENDED, State.ACTIVE))
{
    _stateListener.stateChange(this, State.SUSPENDED, State.ACTIVE);
}
else
{
    // this is a hack to get round the issue of increasing bytes credit
    _stateListener.stateChange(this, State.ACTIVE, State.ACTIVE);
}

This defect is unlikely to affect users as 0xFFFFFFFF gives a bytes credit of 4GB or a message credit limit of more than 4 billion.

Issue Links

• duplicates: QPID-8225 [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer