Skip to main content

[jsr343-experts] Re: (JMS_SPEC-73) Define how messages from a topic are delivered to clustered application server instances

  • From: Nigel Deakin <nigel.deakin@...>
  • To: jsr343-experts@...
  • Subject: [jsr343-experts] Re: (JMS_SPEC-73) Define how messages from a topic are delivered to clustered application server instances
  • Date: Mon, 04 Feb 2013 19:39:36 +0000
  • Organization: Oracle Corporation

No-one gave any feedback on my email below.

As the email below explains, I am coming to the view that implementing the new "subscriptionScope" MDB activation property by requiring the resource adapter to automatically generate the subscription name may not be practical because it would be difficult to implement in a portable way which is guaranteed to work in multiple application servers. This is a problem because I don't think JMS should be defining mandatory features which cannot be implemented portably.

I don't think we will have time to resolve this in time for JMS 2.0, so I therefore propose that we DEFER THIS FEATURE UNTIL JMS 2.1. This will give time to pursue other ways of implementing "subscription scope" which do not rely on the resource adapter generating a subscription name.

This would also defer the associated feature which allows the subscriptionName to be left unset when subscriptionScope was set.

Dropping this feature will probably mean that the JCA EG will drop the new method getActivationName on BootstrapContext that they were adding to support this. The JCA maintenance release is due to be submitted later this week so I need to let them know very soon whether JMS will be using this method or not.

As always, your comments would be welcome.


On 28/01/2013 19:43, Nigel Deakin wrote:
(Summary: This email is an update on progress getting JCA spec and Java EE 
spec changes to allow a resource adapter to
implement support thw new JMS 2.0 activation property subscriptionScope. It 
explains how JMS may not get all the
features we need.)

On 04/12/2012 19:25, Nigel Deakin wrote:
I refer to this JIRA issue
Define how messages from a topic are delivered to clustered application 
server instances


I hope you are familiar by now with Chapter 12 of the JMS 2.0 public draft, 
which defines various standard activation
properties. Amongst the properties defined are subscriptionName and 

The draft specification states that if subscriptionScope is set then the 
resource adapter will automatically generate
the subscription name (durable or non-durable) that will be used. If subscriptionScope 
is "Cluster" then for a given
activation the name will be the same for each instance in the cluster. If 
subscriptionScope is "Instance" the name will
be unique to the activation.

Subsection 12.1.2 "Implementation in a resource adapter" contains some 
information on how a resource adapter might
implement this, using new methods added to the JCA specification.

"The Java EE Connector Architecture (JCA) specification defines a method 
getInstanceName on
javax.resource.spi.BootstrapContext and a method getActivationUniqueName on 
MessageEndpointFactory. If a scope of
cluster is specified then a suitable subscription name may be obtained by 
calling the getActivationUniqueName method. If
a scope of instance is specified then a suitable subscription name may be 
obtained by calling the getInstanceName and
getActivationUniqueName methods and concatenating the results.

"If a scope of instance is specified then a suitable subscription name may be 
obtained by calling the getInstanceName
and getActivationUniqueName methods and concatenating the results.

However if the subscriptionName property and the subscription is durable then 
the value of this property should be used
instead of the value returned by getActivationUniqueName"

The proposed required changes to the JCA specification, I discussed our 
requirements with the JCA spec lead and logged
them as a JCA specification issue:

If you read that issue you will see that I asked that the values returned 
contained only particular characters and that
when combined together were no longer than 128 characters. This is so we can 
be sure that any generated subscriptionName
was valid (as defined in the new 6.11.5 "Subscription name characters and 

I also asked that the names returned should be consistent after the instance 
is restarted or reconfigured (within
reason). We can't have a subscription name changing after a restart.

I met (on the phone) with the JCA EG last week to explain the JMS 
requirements. The JCA expert group has now considered
this proposal and is close to making their final decision. Based on what I've 
heard so far, here's what I am expecting
to happen:

Instance name

I'm expecting the JCA expert group to reject my proposal to add a method to 
BootstrapContext to obtain the "instance
name" on the grounds that it is too Java EE-specific.

Fortunately there is a fallback, which is for the resource adapter to lookup 
the new pre-defined JNDI name
java:comp/InstanceName defined in the Java EE platform spec (see section EE.5.16 
"Application Server Instance Name").

However this currently has no limitations on length or on the characters 

It is defined as follows:

"EE.5.16 Application Server Instance Name

"In some special cases, it may be necessary to identify the name of the 
application server instance in which a component
is executing—for example, when a resource adapter needs to perform endpoint 
activation. A component may access the name
of the application server instance in which it is executing using the 
pre-defined JNDI name java:comp/InstanceName. This
name is represented by a String object. If the application has been deployed 
into a clustered application server, this
name identifies the application server instance within the cluster. This name 
is only guaranteed to be unique within
instances of the same cluster. If the application server is not clustered, it is 
the empty string."

Activation name

I'm expecting the JCA expert group to agree to my proposal to add a method to 
MessageEndpointFactory to obtain the
"activation name".

However it looks as if my proposal for limitations on length and on the 
characters returned have been rejected as being
"too JMS-specific".

Here's the API proposed by the JCA EG:

"java.lang.String getActivationName()

"Returns a unique name for the message endpoint deployment represented by the 
MessageEndpointFactory. If the message
endpoint has been deployed into a clustered application server then this 
method must return the same name for that
message endpoint'ss activation in each application server instance. It is 
recommended that this name be human-readable
since this name may be used by the resource adapter in ways that may be 
visible to a user or administrator. It is also
recommended that this name remain unchanged even in cases when the 
application server is restarted or the message
endpoint redeployed."


My main concern here is that the strings obtained by the resource adapter may 
be of any length and may contain any
characters. The resource adapter will be responsible for converting these 
strings into a valid subscription name which
conforms to the new JMS section 6.11.5 "Subscription name characters and 
length" whilst retaining the necessary
semantics and uniqueness. It's not immediately obvious to me that a resource 
adapter will be able to do this without,
say, using some kind of cluster-wide database to store a mapping between the "long" and 
"shortened" version of each name.

Let's review which use cases are affected by this problem. There are four use 
cases we need to consider:

1. subscriptionScope=Cluster, subscriptionName=unset
2. subscriptionScope=Cluster, subscriptionName=specified
3. subscriptionScope=Instance, subscriptionName=unset
4. subscriptionScope=Intance, subscriptionName=specified

1. subscriptionScope=Cluster, subscriptionName=unset

In this case the subscriptionName used should be based on the activationName 
returned by the MessageEndpointFactory. The
resource adapter will be responsible for ensuring that the subscriptionName 
is of less than 128 characters and contains
only valid characters.

2. subscriptionScope=Cluster, subscriptionName=specified

In this case the subscriptionName used can be the specified subscriptionName. 
No other information is required from the
container. Since the deployer can be required to provide a name of a valid 
length and containing valid characters, there
is no problem here.

3. subscriptionScope=Instance, subscriptionName=unset

In this case the subscriptionName used should be based on the activationName 
returned by the MessageEndpointFactory,
combined with the instance name obtained by JNDI lookup. The resource adapter 
will be responsible for ensuring that the
subscriptionName generated is of less than 128 characters and contains only 
valid characters.

4. subscriptionScope=Instance, subscriptionName=specified

In this case the subscriptionName used should be based on the specified 
subscriptionName, combined with the instance
name obtained by JNDI lookup. The resource adapter will be responsible for 
ensuring that the subscriptionName generated
is of less than 128 characters and contains only valid characters.

My feeling is that in cases 1,3 and 4 we are placing a requirement on the 
resource adapter that it may be difficult to
implement. (Note that use case 4 would still be a problem even if the JCA has 
provided what I asked for).


I haven't come to a firm conclusion yet, but I am beginning to feel that 
implementing subscriptionScope by requiring the
resource adapter to automatically generate the subscription name may not be 
practical because it would be difficult to
implement in a portable way which works in multiple application servers.

What do others think? Should we look at other ways of implementing "subscription 
scope" which does not rely on the
resource adapter generating a subscription name?


[jsr343-experts] Re: (JMS_SPEC-73) Define how messages from a topic are delivered to clustered application server instances

Nigel Deakin 02/04/2013

[jsr343-experts] Re: (JMS_SPEC-73) Define how messages from a topic are delivered to clustered application server instances

Nigel Deakin 02/07/2013
Please Confirm