activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-2651) prefetchExtension off-by-1 for transacted consumers with prefetchSize > 0
Date Tue, 20 Apr 2010 15:18:14 GMT

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

Gary Tully resolved AMQ-2651.
-----------------------------

    Fix Version/s: 5.4.0
       Resolution: Fixed

resolved in r935954

policyEntry.usePrefetchExtension allows the prefetch extension behaviur to be disabled. When
false, and with prefetch of 1 or X, a new message will only be dispatched when the message
is acked, rather than when it is delivered. When false, a client ack consumer  or transacted
consumer will only ever get prefetch (X) number messages. 

code example of it disabled from the test:
{code}
        PolicyMap policyMap = new PolicyMap();
        PolicyEntry defaultEntry = new PolicyEntry();
        // ensure prefetch is exact. only delivery next when current is acked
        defaultEntry.setUsePrefetchExtension(false);
        policyMap.setDefaultEntry(defaultEntry);
        broker.setDestinationPolicy(policyMap);{code}

> prefetchExtension off-by-1 for transacted consumers with prefetchSize > 0
> -------------------------------------------------------------------------
>
>                 Key: AMQ-2651
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2651
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0
>            Reporter: Eugene Rodos
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>         Attachments: OnePrefetchAsyncConsumerTest.java, UsePrefetchExtension_Option.patch
>
>
> Linked to forum discussion: http://old.nabble.com/prefetchExtension-off-by-1-for-transacted-consumers-with-prefetchSize-%3E-0-ts27866123.html
> Hi,
> I've searched the forum and JIRA and have noticed that the prefetchExtension in PrefetchSubscription
has caused grief before.  However, I think there's still a problem.
> First, I understand the purpose of the prefetchExtension for the case when prefetchSize
= 0.  It allows messages to be dispatched to the consumer when the consumer requests them
(i.e. polls them).  However, I don't really understand the purpose of the prefetchExtension
for the cases when prefetchSize > 0.  If the consumer has set the prefetchSize to x, shouldn't
it always receive only x messages at a time?  Why is the prefetchSize being extended?  I see
that it is only extended in the case when the message delivery is transacted but I still don't
understand why this is necessary.
> In any case, assuming the prefetchExtension is necessary in the case of prefetchSize
> 0 and transacted message delivery, I think the calculation of the prefetchExtension in
this case has an off-by-1 error.  I am attaching a junit test that illustrates this problem.
> The test is basically acting like a JCA Resource Adapter and sets up an asynchronous
message listener by creating a ConnectionConsumer with a maxMessages value of 1.  This translates
into a PrefetchSubscription with a prefetchSize of 1.  The test then sends 3 messages.  The
purpose of the 1st message is to trigger the prefetch extension logic in PrefetchSubscription
upon the message's ack.  When this happens, the prefetchExtension is set to 1 and the prefetchSize
essentially becomes 2.  I believe this is incorrect and is the off-by-1 error (assuming the
prefetchExtension is required at all in this case).  The 2nd message is simulated to be a
long running message so that when the 3rd message is dispatched, the 2nd message is still
being processed.  When the 3rd message is dispatched, because the prefetchSize has been extended,
it will try to deliver it even though the processing of the 2nd message has not been completed
and even though maxMessages on the ConnectionConsumer was specified as 1.
> Now, if I only have 1 ServerSession in the ServerSessionPool, this behavior seems to
violate the JMS Spec since the maxMessages parameter used during ConnectionConsumer creation
is defined as "the maximum number of messages that can be assigned to a server session at
one time" and ActiveMQ is trying to assign 2 messages to the same ServerSession at the same
time. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message