Robert Greig wrote:
On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
The java broker may not have a DLQ, but any broker being conservative
about exactly once semantics will need to have a DLQ for messages that
may have been processed by a client. Messages sent on a connection that
was aborted would fall into this category.
OK I can see your point but this implies also (I think?) that when the
consumer calls close() that it processes any messages that have been
prefetched. We certainly do not do that.
In JMS, close() is the only method that can be called by any thread
and we simply stop processing. Are you suggesting that when you call
close() on a session it should deliver all prefetched messages on all
consumers?
In 0-10 there is a message.release that may be used to inform the broker
that prefetched messages were not actually processed. I don't think
there is a way to do this in 0-8 without either extending the spec or,
as you suggest, processing all prefetched messages.
There is a difference between a clean shutdown and an abort. A clean
shutdown will always involve some sort of handshake. So while you
definitely want to be as graceful as possible in the case of an abort,
there will fundamentally be unresolved state without the handshake, and
many applications will not be able to tolerate that unresolved state.
Any application that needs that can call close() explicitly on the consumer.
That's true, however I would think that the expected JMS behavior would
be for connection close to do a clean shutdown.
--Rafael
