[
https://issues.apache.org/activemq/browse/AMQ-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56908#action_56908
]
Rudolf Janz commented on AMQ-2567:
----------------------------------
Gary Tully wrote:
PrefetchSubscription and prefetchExtension on a deliveryAck in a transaction
are areas that you need to look into to resolve this. Great that you have a
simple junit test case.
---
You are right, prefetchExtension is the problem. I do not understand the reason
for it. If I want prefetch 0, it should stay that way. Right now it is
increased on each pull.
In acknowledge there is the following comment
if (context.isInTransaction()) {
// extend prefetch window only if not a pulling consumer
if (getPrefetchSize() != 0) {
prefetchExtension = Math.max(
prefetchExtension, index );
In PrefetchSubscription::pullMessage it checks for prefetchSize 0
if (getPrefetchSize() == 0 && !isSlave()) {
final long dispatchCounterBeforePull;
synchronized(this) {
prefetchExtension++;
dispatchCounterBeforePull = dispatchCounter;
}
> Zero Prefetch not working
> -------------------------
>
> Key: AMQ-2567
> URL: https://issues.apache.org/activemq/browse/AMQ-2567
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.0
> Environment: Unix/Windows, Java 1.6
> Reporter: Rudolf Janz
> Attachments: ZeroPrefetchConsumerTest.java
>
>
> I have problems using the zero prefetch. The consumer starts prefetching
> messages after some receives.
>
> Our use case is, that we have a large computation which is split into smaller
> sub jobs. These jobs are sent via ActiveMQ to some processing nodes on
> different machines. The duration of jobs differs very much (10s to some
> minutes). The jobs are sent by decreasing estimated computation time. If one
> of the consumers which receives a large job prefetches some other jobs, these
> will be processed later. In the meantime the remaining consumers are idle,
> and the total computation time is much longer than necessary.
>
> I have modified the existing ZeroPrefetchConsumerTest to test for the problem
> (I have removed the other test methods).
>
> Two consumers (C1 and C2) are instantiated. These messages are sent:
> 1,2,3,4,5,6,7,8,9
>
> C1 reads 4 times, receives 1,2,3,4 -> this is correct
>
> now C2 reads, it receives 8 not 5, which is the next message in the queue.
> The reason is, that C1 prefetched 5, 6, 7, that should not have
> happened.(sometimes C1 only prefetches 5,6)
>
> The problem can be seen in the JMX Console as well, after a while, the first
> consumer has more than one dispatched message and the queue has an
> InflightCount of 3, although there are only two consumers!
>
> The last version that we used was 4.1.1, that worked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
