Rafael Schloming wrote:
Gordon Sim wrote:
The reliability model in my view sets the expectation that a message
stays on a queue until acked or until explicitly rejected.
I'm really not suggesting that unacked messages should be arbitrarily
dequeued willy-nilly. What I'm suggesting is that brokers should have
room to detect that a particular message is causing a client to crash.
See my other email for more details on this.
I actually don't see how brokers can know why a client is crashing, and
feel that dealing with poisened messages is something for the
application/system to handle (using reject or admin functions).
If a broker implementation decided to offer something like you are
describing that would be fine in my view, but it would be a non-standard
option (and should therefore be something that can be turned off).
However I think allowing or suggesting that possibility in the spec
would be a bad thing (unless very clearly qualified). Its important for
applications to be able to rely on the fact that unacked messages remain
on their original queue.
This was really a bit of a tangent though, and that issue is probably
more relevant for the AMQP WG.
[...]
In my view normal open/close of
sessions and consumers should never cause redelivery of messages. C-c,
kill -9, network outages are all another matter of course, but IMHO
session.close() or consumer.close() is the thing that you try *before*
resorting to C-c or kill -9.
For 0-10 I agree with you. It makes sense to release messages explicitly
during a clean shutdown and Session.close, MessageConsumer.close seem to
be the places to do that. (You are right of course that these are
equivalent based on the Javadoc).
[...]
However I don't think that retrofitting release is any better than
using reject in a way that may not be portable. Neither cases is
guaranteed to work with other brokers, but adding a new method seems
even less likely to be interoperable.
The idea is to fail fast rather than fail subtly by using reject in a
non standard way. For interoperability I think that continuing to
process prefetched messages is the way to go.
I think I would find it odd if an implementation kept pumping through
messages after I called close, particularly calling it on a Session.
That should at least be an option; after all perhaps the session is
being closed because processing has to be interrupted due to
unavailability of some resource, or due to a user action.
