On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > 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
Is it not possible to use the message.reject in 0_8 to return messages. IIRC the strict AMQP 0_8 reject causes that consumer never to see the message again. Not a huge problem as the consumer is closing. -- Martin Ritchie
