qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-2848) BasicMessageConsumer_0_10 contains dead and questionable code
Date Wed, 02 Nov 2011 10:05:32 GMT

     [ https://issues.apache.org/jira/browse/QPID-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Keith Wall updated QPID-2848:
-----------------------------

    Description: 
In BasicMessageConsumer_0_10, there is a field named _preAcquire. Its value is set true by
default and toggled false at construction time if the given destination is an instance of
AMQQueue.

During the notifyMessage() method, when client side selector evaluation of the incoming message
is performed in the checkPreConditions() method, if the filter indicates the message is not
a match then the _preAcquire field is used to determine acknowledgment and/or release actions
to take that would seem to indicate the _preAcquire field is meant to describe the session
acquire mode. Judging this value based on the incoming destination does not seem correct as
this is actually a property of the Session used. 

Subsequent to the above mentioned uses the _preAcquire field is also used to determine whether
to accept the message.

Further to the above, the code called to perform acknowledgement and releases is dead and
can never actually execute because it too depends on the _preAcquire field but inverted from
the previous use:

if (_preAcquire)
{
    ...
    acknowledgeMessage(message);
}
else
{
    ...
    releaseMessage(message);
}

followed by:

private void acknowledgeMessage(AbstractJMSMessage message) throws AMQException
{
    if (!_preAcquire)
    {
        ...
    }
}

and:

private void releaseMessage(AbstractJMSMessage message) throws AMQException
{
    if (_preAcquire)
    {
        ...
    }
}


  was:
In BasicMessageProducer_0_10, there is a field named _preAcquire. Its value is set true by
default and toggled false at construction time if the given destination is an instance of
AMQQueue.

During the notifyMessage() method, when client side selector evaluation of the incoming message
is performed in the checkPreConditions() method, if the filter indicates the message is not
a match then the _preAcquire field is used to determine acknowledgement and/or release actions
to take that would seem to indicate the _preAcquire field is meant to describe the session
acquire mode. Judging this value based on the incoming destination does not seem correct as
this is actually a property of the Session used. 

Subsequent to the above mentioned uses the _preAcquire field is also used to determine whether
to accept the message.

Further to the above, the code called to perform acknowledgement and releases is dead and
can never actually execute because it too depends on the _preAcquire field but inverted from
the previous use:

if (_preAcquire)
{
    ...
    acknowledgeMessage(message);
}
else
{
    ...
    releaseMessage(message);
}

followed by:

private void acknowledgeMessage(AbstractJMSMessage message) throws AMQException
{
    if (!_preAcquire)
    {
        ...
    }
}

and:

private void releaseMessage(AbstractJMSMessage message) throws AMQException
{
    if (_preAcquire)
    {
        ...
    }
}


        Summary: BasicMessageConsumer_0_10 contains dead and questionable code  (was: BasicMessageProducer_0_10
contains dead and questionable code)

(Replaced references to BasicMessageProducer_0_10 with BasicMessageConsumer_0_10 as this was
the original intention of the Jira).
                
> BasicMessageConsumer_0_10 contains dead and questionable code
> -------------------------------------------------------------
>
>                 Key: QPID-2848
>                 URL: https://issues.apache.org/jira/browse/QPID-2848
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M3, M4, 0.5, 0.6
>            Reporter: Robbie Gemmell
>            Assignee: Keith Wall
>
> In BasicMessageConsumer_0_10, there is a field named _preAcquire. Its value is set true
by default and toggled false at construction time if the given destination is an instance
of AMQQueue.
> During the notifyMessage() method, when client side selector evaluation of the incoming
message is performed in the checkPreConditions() method, if the filter indicates the message
is not a match then the _preAcquire field is used to determine acknowledgment and/or release
actions to take that would seem to indicate the _preAcquire field is meant to describe the
session acquire mode. Judging this value based on the incoming destination does not seem correct
as this is actually a property of the Session used. 
> Subsequent to the above mentioned uses the _preAcquire field is also used to determine
whether to accept the message.
> Further to the above, the code called to perform acknowledgement and releases is dead
and can never actually execute because it too depends on the _preAcquire field but inverted
from the previous use:
> if (_preAcquire)
> {
>     ...
>     acknowledgeMessage(message);
> }
> else
> {
>     ...
>     releaseMessage(message);
> }
> followed by:
> private void acknowledgeMessage(AbstractJMSMessage message) throws AMQException
> {
>     if (!_preAcquire)
>     {
>         ...
>     }
> }
> and:
> private void releaseMessage(AbstractJMSMessage message) throws AMQException
> {
>     if (_preAcquire)
>     {
>         ...
>     }
> }

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


Mime
View raw message