From: Matthew White <WHITEMAT_at_uk.ibm.com>
Date: Fri, 19 Dec 2014 13:32:17 +0000

Hello

(1) Happy the wording; I think I would prefer if we could set a direction
i.e. give a recommended approach. However that would depend on the second
point and a choice for 2.1
Though I do like the wording on applications should not use this
(2) I can certainly see the benefit in having a message listener be able
to stop (and restart) the connection/context. Allows the code processing
the message to be able to spot situations in error either with the
messages or with the an external system and slow down message consumption.


Close I'm less convinced about to be honest. Thinking that for a single
listener to close down an entire infrastructure of consumers could be too
much. Need to think some more.



Regards,

Matthew B. White
Architect: IBM MQ JMS, Connectivity & Integration

Phone: 44-1962-817653
E-mail: WHITEMAT_at_uk.ibm.com
About.me: about.me/matthewbwhite
Find me on: and within IBM on:


Hursley Park
Hursley , SO212JN
United Kingdom
"The wrong answers are the ones you go looking for when the right answers
stare you in the face."





From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: users_at_jms-spec.java.net
Date: 18/12/2014 17:58
Subject: [jms-spec users] Re: JMS 2.0 Errata: JMS_SPEC-158 (JMS 2.0
introduced incompatible changes to Connection.stop and close and
Session.close)



I haven't received any comments on this so far.

For a detailed description of what the problem is, please see my earlier
email or my description in
https://java.net/jira/browse/JMS_SPEC-158. But essentially we need to
amend the specification to allow JMS providers
which allowed Session#close, Connection#stop and Connection#close to be
called from a message listener on its own
session or connection to continue to do so.

I circulated some draft javadoc changes on 27th November. For example, I
suggested that the definition of
Connection#close be changed as follows:

Existing text:

      When this method is invoked, it should not return until message
      processing has been shut down in an orderly fashion. This means that
all
      message listeners that may have been running have returned, and that
all
      pending receives have returned.

Replacement text:

      When this method is invoked, it should not return until message
      processing has been shut down in an orderly fashion. This means that
all
      message listeners that may have been running have returned, and that
all
      pending receives have returned.

          However if the close method is called from a message listener on
its own
          connection, then it will either fail and throw an
<tt>IllegalStateException</tt>,
          or it will succeed and close the connection, blocking until all
other
          message listeners that may have been running have returned, and
all
          pending receives have returned. If close succeeds and the
acknowledge mode
          of the session is set to AUTO_ACKNOWLEDGE, the current message
will still
          be acknowledged automatically when the onMessage() call
completes.

          Since two alternative behaviors are permitted in this case,
applications
          should avoid calling close from a message listener on its own
          connection because this is not portable.

There are two issues which need to be decided before I can draft the final
changes.

1. Given that the spec will allow the close to "succeed" as an alternative
to throwing an exception, it needs to define
what this means, given that the current definition of close would, if
followed strictly, would lead to deadlock. Is the
text proposed above OK?

2. We also have to decide whether the same change should be made to the
new JMS 2.0 methods JMSContext#stop and
JMSContext#close. If we followed the same approach as for my other
proposals we would leave these methods unchanged
since there is no need to change them, and it is better to stick with the
current, unambiguous, definition.

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).

If we decided that, the errata could allow either behaviour (so existing
implementations don't need to change), and then
in JMS 2.1 we could remove the option to throw an exception (which we
could reasonably argue wasn't an incompatible
change to applications).

I'm attracted by this, as I've received complaints that requiring an
exception to be thrown has made it harder to write
applications.

What do people think of that? I'd welcome views.

Nigel



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU