[
https://issues.apache.org/jira/browse/QPID-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16881407#comment-16881407
]
Rob Godfrey commented on QPID-3616:
-----------------------------------
I believe this was fixed in QPID-8225 (there was a recent change in QPID-8322
which got rid of one wrinkle),
> Java Broker misinterprets message.flow infinite credit value (0xFFFFFFFF)
> -------------------------------------------------------------------------
>
> Key: QPID-3616
> URL: https://issues.apache.org/jira/browse/QPID-3616
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: 0.13
> Reporter: Keith Wall
> Priority: Major
>
> 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.
> {code}
> 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);
> }
> {code}
> 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.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
