[ 
https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36716 ] 
            
james strachan commented on AMQ-855:
------------------------------------

Andrew I just commented on this thread on why a prefetch of 1 is the lowest 
possible value to have while still fully implementing the JMS spec...

http://www.nabble.com/forum/ViewPost.jtp?post=5583273&framed=y

A few further comments...

> Now, you could in theory hack together a "pull" model by setting prefetch 
> size = 0, so that basically each ack is a request for the next message

Thats a prefetch of 1. With a prefetch of zero no messages would be dispatched 
so there could be no ack :)


> Systems like this need to be designed under the assumption that clients will 
> not behave themselves. 
> They will deadlock themselves, slow down arbitrarily, boxes will go up and 
> down, etc. 
> These things happen all the time in real life and shouldn't have adverse 
> effects on other, well-behaved consumers.

This is a valid problem - a badly behaving consumer can hog a message. However 
changing from a push to pull model or having prefetch of 0 or 1 will not change 
this. A hogged message is a hogged message however the consumer manages to get 
the message (pull or push).

e.g. if we did implement prefetch of zero - which means don't deliver a message 
to a consumer at all - unless they perform a consumer.receive() - even then, 
the consumer could then hang/deadlock and never actually acknowledge or process 
the message.

The workaround to this is to just kill consumers if they take too long to 
process a message - see this JIRA which I think what you really need

http://issues.apache.org/activemq/browse/AMQ-850


> Add support for prefetchSize = 0
> --------------------------------
>
>                 Key: AMQ-855
>                 URL: https://issues.apache.org/activemq/browse/AMQ-855
>             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: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to