[
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:[email protected]
