You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (Created) (JIRA)" <ji...@apache.org> on 2011/11/15 11:03:54 UTC

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

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: Java Broker
    Affects Versions: 0.13
            Reporter: Keith Wall


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 is 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


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

Posted by "Keith Wall (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Wall updated QPID-3616:
-----------------------------

    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.

{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.



 




  was:
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 is 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.



 




    
> 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: Java Broker
>    Affects Versions: 0.13
>            Reporter: Keith Wall
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org