On 26/12/2014 18:04, Chris Barrow wrote:
> Hi Nigel,
>
> From one of your previous emails:
>> However there is one reason why we might want to keep the simplified API consistent with the classic API, and allow
>> stop and close to be called in all cases. This is if we decided that it is actually better to allow stop and close to
>> be called than throw an exception (i.e. requiring an exception was a mistake).
>>
> I am strongly in favor of this approach, for several reasons: first, consistency is always better; second, the ability
> to call stop and close from within a message listener is a useful feature for flow control purposes, as Matthew pointed
> out, or to allow remote control of an application. Then for 2.1 we can remove the option to throw an exception.
>
Thanks for your feedback (and your comment on the JIRA issue), and to everyone else who replied, both publicly and
privately. I've been thinking carefully about what the best option is here and have come to the conclusion that the best
option is to keep the simplified API consistent with the classic API, and allow stop and close to be supported in all
cases as an alternative to throwing an exception. Since this will be optional it doesn't require changes to existing
implementations or applications. I will be proposing that in JMS 2.1 we remove the option to throw an exception, if we
can satisfy ourselves that this does not itself constitute an incompatible change.
As I have explained before, we need to make this change for the classic API anyway because the JMS 1.1 specification
contained an error that required deadlock to occur, and we don't want to force an incompatible change (throwing an
exception) on JMS providers which in good faith decided to work around that error.
What I doing now is to extend this change to the simplified API, not to be consistent (which is not a requirement,
especially if we were sure that the simplified API was right), but because with hindsight I think that the change in JMS
2.0 that required an exception to be thrown was a mistake. Allowing a message listener to "shut itself down" is a
genuinely useful feature and that forbidding it in the simplified API would be placing a barrier to some applications
adopting it.
Nigel