Gordon Sim wrote:
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.
We could always indicate to the listener that the session/consumer is
closing, e.g. set a header indicating that the message passed to the
listener was prefetched. That way the application itself could decide
how urgent the need to close is and whether throwing away the message is
warranted or not. I think we'd have to do something like this for no-ack
since, as you pointed out, there is no way to release those messages
back to the broker.
--Rafael
