activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Pesochinskiy (JIRA)" <>
Subject [jira] Commented: (AMQ-855) Add support for prefetchSize = 0
Date Wed, 09 Aug 2006 00:27:23 GMT
    [ ] 
Vadim Pesochinskiy commented on AMQ-855:

I agree this functionality is essential for slow consumers. I do not see the hacking part
in it. If prefetchSize is set to 0 client cannot expect messages dispatched to it, so it has
to send an ack to get next msg.

Of course push will work better when a lot of messages are sent. In this case AMQ-850 will
fix it by timing out and disabling passive consumers.

> Add support for prefetchSize = 0
> --------------------------------
>                 Key: AMQ-855
>                 URL:
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 4.0, 4.0.1, 4.0.2
>         Environment: any
>            Reporter: Vadim Pesochinskiy
>            Priority: Critical
>             Fix For: 4.2
> This feature would enable to support following test case:
> 2 servers are processing 3 submitted jobs with following processing times 10 min, 1 min,
1 min. This sequence should finish in 10 minutes as one service will pick up the 10 minutes
job, meanwhile the other one should manage the two 1 minute jobs. Since I cannot set prefetchSize=0,
one of the 1 minute jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes
instead of 10.
> This is simplification of the real scenario where I have about 30 consumers submitting
jobs to 20 consumers through AMQ 4.0.1. I have following problems:
> • Messages are sitting in prefetch buffer are not available to processors, which results
in a lot of idle time.
> • Order of processing is random. For some reason Job # 20 is processed after Job # 1500.
Since senders are synchronously blocked this can result in time-outs.
> • Some requests are real-time, i.e. there is a user waiting, so the system cannot wait,
so AMQ-850 does not fix this issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message