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