activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rodos77 <eugene.ro...@nexj.com>
Subject Re: prefetchExtension off-by-1 for transacted consumers with prefetchSize > 0
Date Thu, 18 Mar 2010 22:05:38 GMT

I don't really get this.  If you extend the prefetchSize to more than what it
was configured to be by the maxMessages parameter in the
Connection.createConnectionConsumer() call, you are violating the JMS spec. 
The maxMessages parameter is defined as "the maximum number of messages that
can be assigned to a server session at one time", so how can you make it
bigger than what it was set to by the ConnectionConsumer?!

ActiveMQ Resource Adapter has 2 parameters in its ActivationSpec that
control the maxMessages argument used in the
Connection.createConnectionConsumer() call: maxSessions and
maxMessagesPerSessions.  The maxMessages argument is set to their product. 
This makes sense.  If a user configures ActiveMQ to have x maxSessions and y
maxMessagesPerSessions, maxMessages (and consequentially the prefetchSize)
should be set to x*y.  But why should this ever be extended?  Shouldn't it
be expected that only a maximum of x*y messages be delivered at the same
time?  If a user wants to process z <= x*y messages in the same tx, that
should not pose any problem as the RA will have x ServerSessions each
capable of processing y messages at the same time.  But if the user wants to
process z > x*y messages at the same time after explicitly configuring
ActiveMQ to only deliver a maximum of x*y messages at the same time, this is
a user error/problem.  ActiveMQ should not be violating the JMS Spec to
accommodate this.  What is the point of having those properties in the 1st
place if you are going to extend them and deliver as many messages as
available?



Gary Tully wrote:
> 
> The prefetch extension in the transacted case is necessary for the case
> where a transacted consumer wants to consumer more than prefetch messages
> in
> a single transaction. Without the extension, the broker would see a full
> prefetch and not dispatch any more and a receive could block.
> 
> On 15 March 2010 21:31, rodos77 <eugene.rodos@nexj.com> wrote:
> 
>>
>> JIRA AMQ-2651 opened.
>>
>> I would be happy to provide a patch but as I stated in my original post,
>> I
>> don't fully understand the need for prefetchExtension in the case of a
>> transacted, asynchronous (prefetchSize > 0) consumer.  If somebody could
>> explain it, that would perhaps give me the required knowledge to come up
>> with a patch.
>>
>> The way I see it now, I would get rid of the prefetchExtension (in the
>> above
>> mentioned case) all together, but again I'm probably missing some piece
>> of
>> information and I don't want to cause any side effects.  Barring that, I
>> think there is an off-by-1 error in its calculation but I need this
>> confirmed in order to create a proper patch.
>> --
>> View this message in context:
>> http://old.nabble.com/prefetchExtension-off-by-1-for-transacted-consumers-with-prefetchSize-%3E-0-tp27866123p27910673.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
> 
> 
> -- 
> http://blog.garytully.com
> 
> Open Source Integration
> http://fusesource.com
> 
> 

-- 
View this message in context: http://old.nabble.com/prefetchExtension-off-by-1-for-transacted-consumers-with-prefetchSize-%3E-0-tp27866123p27950855.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message