Looks like I replied before seeing your followup :)
> To expand a little further... The behaviour I'm thinking about for 0-9-1 > would be that on a synchronous session, every time you call receive() the > client opens up the credit window enough for you to receive a message if > there isn't currently credit enough to get the message. At the point a > commit occurs (on a transacted session), or an acknowledge (on a client > ack > session), the window is reduced again such that no new messages will be > prefetched until a receive is called... And also if the window could be reduced when "receive" times out, mainly to prevent a message that arrives after we've started working on the previously dequeued set of message. > The other (potentially simpler for me, but hackier) possibility would be > to > provide some way of allowing you to manually flex the prefetch size on an > individual session... this would probably require casting into a qpid > specific class for you so you could directly manipulate the session > object. Would the manual re-sizing be done dynamically or only at session creation time? For us, over-sizing (setting prefetch of 10 when there are only 8 messages at the moment) could lead to the starvation of late arrival messages mentioned above. Cheers! Dan -- View this message in context: http://qpid.2158936.n2.nabble.com/Synchronous-consumer-can-only-dequeue-1-message-in-AMQP-0-91-tp7613017p7613072.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
