Robert Greig wrote:
What do you mean by "add the release method from 0-10"?
I do agree that processing prefetched messages is not the ideal
behavior, however it is the only one available if you want to strictly
adhere to AMQP semantics, and I would expect it to also comply with JMS
semantics presuming that you block the session.close() call until
processing of prefetched messages is complete.
Is it not really up to the client developer not to use prefetch if he
wants to use NO_ACK, not call consumer.close() and still quiesce the
session? For example, how do you process prefetched messages for
consumers that do not have a message listener, i.e. where messages are
processed using receive()?
In 0-8 both prefetch limits are ignored when no-ack is true, so there is
no way to turn off prefetch when you're using no-ack. In 0-10 it is
possible to use flow control with no-ack since the flow control dialog
has been decoupled from message acknowledgment, however it would
entirely defeat the purpose of no-ack to not be able to use prefetch.
Also it doesn't really matter whether you use prefetch since even if you
explicitly request each message to be sent prior to processing, close()
could still be called after that request is sent. In other words not
using prefetch is the same as having a prefetch of 1 which doesn't
eliminate the problem it simply reduces the impact to a single message
at the cost of reasonable performance.
Regarding prefetching for consumers that do not have a message listener,
you're right that it is inherently unsafe without the ability to release
messages.
--Rafael
