[ https://issues.apache.org/jira/browse/AMQ-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171203#comment-14171203 ]
Robbie Gemmell edited comment on AMQ-5379 at 10/14/14 4:50 PM: --------------------------------------------------------------- Separately, the consumer prefetching has some issues from an AMQP perspective, possibly due to a bit of a mismatch between how the internal consumer prefetch handling of the broker works (being set to a particular size window initially), and how the explicit handling of credit in AMQP 1.0 works (consumers explicitly grant/retract credit for the server to use to send messages, as and when appropriate to satisfy the consumer clients needs). >From an AMQP perspective, a consumer can attach without any credit initiall, >then grant it later when it is deemed appropriate to receive messages, and >also retract it to ensure it doesnt get any messages during a period when it >doesnt want any. These behaviours could be combined to implement 0-prefetch >synchronous recieve for example. Currently it would seem that due to the >default prefetch value the broker may send messages to the client in cases >where it hasnt yet 'asked' (provided any credit) for them, or in cases where >it has asked not to get any more until further notice, which could cause >problems. It is possible that Proton will handlethis, by buffering all the >messages that there is not credit to send, which in itself could cause >problems later or lead to some interesting memory usage. was (Author: gemmellr): Separately, the consumer prefetching has some issues from an AMQP perspective, possibly due to a bit of a mismatch between how the internal consumer prefetch handling of the broker works (being set to a particular size window initially), and how the explicit handling of credit in AMQP 1.0 works (consumers explicitly grant/retract credit for the server to use to send messages, as and when appropriate to satisfy the consumer clients needs). >From an AMQP perspective, a consumer can attach without any credit initiall, >then grant it later when it is deemed appropriate to receive messages, and >also retract it to ensure it doesnt get any messages during a period when it >doesnt want any. These behaviours could be combined to implement 0-prefetch >synchronous recieve for example. Currently it would seem that due to the >default prefetch value the broker may send messages to the client in cases >where it hasnt yet 'asked' (provided any credit) for them, or in cases where >it has asked not to get any more until further notice, which could cause >problems. > AMQP - allow setting prefetch size > ---------------------------------- > > Key: AMQ-5379 > URL: https://issues.apache.org/jira/browse/AMQ-5379 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP > Affects Versions: 5.10.0 > Reporter: Dejan Bosanac > Assignee: Dejan Bosanac > Fix For: 5.11.0 > > > Currently the prefetch size is hardcoded to the value of 100 -- This message was sent by Atlassian JIRA (v6.3.4#6332)