users@jms-spec.java.net

[jms-spec users] Minutes of JMS 2.1 Meeting 3 on 19 Nov 2014

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 20 Nov 2015 12:35:35 +0000

We held our third JMS 2.1 meeting (the second virtual meeting) at 0900 PST on Thursday 19 Nov 2015. Here are some
minutes. As always, feel free to reply and make comments (irrespective of whether you were at the meeting or not)

Next meeting
------------

Next week is the US Thanksgiving holiday, so our next meeting is in TWO weeks, on Thursday 3rd Dec at 0900 PST.

Details at
https://java.net/projects/jms-spec/pages/JMS21Meetings

Agenda
------

As stated in the previous minutes, the aim of the meeting was to continue working on the method annotations (perhaps
coming to a conclusion) before moving on to discussing the method signature itself.

1. Introductions
-------------

Nigel Deakin (Oracle, Spec lead, UTC)
Tom Barnes (Oracle, UTC-5)
David Blevins (Tomitribe, EG member, UTC-8)
Werner Keil (EG member, UTC+1)
Ryan Cuprak (UTC-5)

2. Flexible JMS MDBs: discussion of method annotations
------------------------------------------------------

Nigel had previously written up the previous meeting's conclusions at
https://java.net/projects/jms-spec/pages/JMSListener5
and the whole meeting was spent reviewing that page and in particular discussing the open issues listed on that page

2.1 Annotations for topic subscriptions
---------------------------------------

In practice most of the time was spent discussing the annotations for topic subscriptions, and in particular how the
user would specify the durable subscription name and the client identifier. We had two main options

Option A

  @TopicListener("java:global/topicName")
  @DurableSubscription(name="mySubName", clientId="myClientId")

or option B

  @TopicListener("java:global/topicName")
  @DurableSubscription
  @SubscriptionName("mySubName")
  @ClientId("myClientId")

though we contemplated other variations.

Aspects discussed included:

* Option A requires fewer annotations overall for the user to remember. If the user types @DurableSubscription then
their IDE can remind them that they can specify name and clientId.

* Option B is consistent with the approach taken for other annotations, which is that each annotation specifies a single
piece of information and has zero or one element. Having just one element means we can call it "value" which means the
user can omit the name of the element (i.e. can specify @Foo(bar) instead of @Foo(value=bar).

* Option B allows the user to configure clientId when using a queue. Option A does not. The JMS spec states that client
identifier is a property of the connection and is not restricted to topic. The EJB 3.2 specification defines clientId as
a standard activation property but does not restrict it just to topics. This suggests option B.

* The JMS spec states that the only use of clientId defined by JMS is in various cases with topics. This supports option A.

* Although the user may wish to set durable subscription name and client identifier, in the ideal case the user doesn't
need to set them. This is because these are really implementation details: all the user cares about is that if they shut
down a particular app server and restart it, the same deployed MDB will use the same durable subscription as it did
before the shutdown. This can be achieved by the container setting clientId and subscriptionName automatically to a
value such as the MDB name concatenated with some kind of server name. Both Glassfish and Weblogic do that, and Nigel
suggested other app servers do too. However it was unclear whether this made option A or option B more suitable.

* JMS 2.0 defines "shared subscriptions" which may be durable or non-durable. However in JMS 2.0/EJB 3.2 this
distinction is not exposed to JMS MDBs: a user cannot specify whether the subscription is shared or not.

In the future it might be desirable to allow the user to specify this, particularly when deploying the MDB into a
cluster. If we do, how would we need to change the annotations? Which of the two options would make this easier? In
particular, how would the user specify the name of a shared non-durable subscription? Only option B would allow that.

However Nigel suggested that what the user really wanted to control was how a MDB (that consumed from a topic) behaved
when deployed into in a cluster: did each server instance use a separate subscription or did all servers share the same
subscription. This means that they wanted to define the required "semantics". For example when discussing JMS 2.0 we
considered allowing a new property "subscriptionScope" to be "server" or "cluster", though this feature was dropped in
the end. In WLS there is an existing non-standard extension which offers the choice of "one-message-per-server" or
"one-message-per-application" semantics. Glassfish has a non-standard "share subscriptions in clustered container"
feature. In all cases the user does not specify clientId or subscription name: these are set internally. SoO perhaps
there would never be a need to specify subscription name for non-durable subscriptions, which means either option A or B
would work.

It was surprisingly difficult to come to a conclusion. In the end Nigel suggested that we go for option B, at least for
the time being, on the following grounds:

* This is consistent with general approach in which each annotation specifies a single piece of information.

* This offers the most flexibility in the future.

* We still had plenty of time to change our mind before release.

2.2 Annotations for acknowledgement mode
----------------------------------------

The meeting discussed the annotations for specifying that the MDB should use auto-ack or dups-OK-ack. The working
proposal in https://java.net/projects/jms-spec/pages/JMSListener5 was for

* @AutoAcknowledge to specify auto-ack. User had also to configure BMT (e.g. using
@TransactionManagement(TransactionManagementType.BEAN))

* @DupsOKAcknowledge to specify dups-ok-ack. User had also to configure BMT (e.g. using
@TransactionManagement(TransactionManagementType.BEAN))

* RA/container would be recommended to fail deployment if the user specifies @AutoAcknowledge or @DupsOKAcknowledgeto
but forgets to configure BMT.

We first discussed whether to define a third element such as @javax.jms.Transactional or @javax.jms.AssertTransactional
which could be used to state that a container-managed XA transaction was required, with the application server or
resource adapter being recommended to fail deployment if the user had configured bean-managed transactions. It was
agreed we needed more time to discuss this. There was concern that this would be confusing since we already have two
overlapping annotations @TransactionManagement and @javax.transaction.Transactional, and this would add a third.

After David left the meeting Werner suggested that we should merge AutoAcknowledge and DupsOKAcknowledge into a single
annotation such as:

@AcknowledegeMode(AcknowledegeMode.AutoAcknowledge)
@AcknowledegeMode(AcknowledegeMode.DupsOKAcknowledge)

Tom agreed and suggested a third mode something like

@AcknowledegeMode(AcknowledegeMode.Transaction)

We agreed we should discuss this at the next meeting.

The meeting closed after about 90 minutes.

Side-action
-----------

As a side issue, David asked whether a shared non-durable subscription and a durable subscription can have the same
subscription name. Nigel said he'd check. Here's the answer:

JMS 2.0 section 8.3.2 states "There is no restriction to prevent a shared non-durable subscription and a durable
subscription having the same name. Such subscriptions would be completely separate."

Section 8.3.3 states "A shared durable subscription and an unshared durable subscription may not have the same name and
client identifier."

This means that
* durable subscriptions and non-durable subscriptions use separate name spaces
* the durable subscription namespace is use by shared and unshared durable subscriptions
* a given durable subscription can't be both shared and unshared at the same time. You'll get an error if you try.

Nigel