I received some feedback on the public draft from Mike Marzo. JCP member representing Goldman Sachs. I've forwarded it
here (below) with permission and will reply shortly.
Nigel
*
Commentson the Public Draft*
*_Clarifications_
*
*Load balancing for shared non-durable and durable subscriptions*
When a shared subscription has multiple consumers, are there any fairness/load-balancing guarantees around how messages
will be distributed to each of these consumers?
*Semantics of Session.unsubscribe when using shared subscriptions
*
The specification is not clear on the semantics of Session.unsubscribe when using shared subscriptions.
Consider the case where a shared subscription has consumers in two different clients. When the first client calls
Session.unsubscribe, does it result in the subscription being removed for both the clients? Or does Session.unsubscribe
take effect only if there are no active message consumers for the subscription?
*Sending messages asynchronously - commit completion
*
The specification is explicit about the completion of CompletionListener callbacks for locally transacted sessions, but
does not say anything about XA sessions.
/If the session is transacted (uses a local transaction) then when the commit or rollback method is called the JMS
provider must block until any incomplete send operations have been completed and all CompletionListener callbacks have
returned before performing the commit or rollback./
Even with XA sessions, commit(on the JTA transaction manager, transaction object) will block till all CompletionListener
callbacks have been completed?
*Sending messages asynchronously - callback completion order
*
Should the specification clarify that there are no guarantees about the order in which the CompletionListener callbacks
will be called?
Specifically, if message1 is sent before message2, the callback for message2 can be invoked before the callback for
message1?
_*Suggestions/Enhancements*_
*Context creation using the new API - "Unspecified session mode"*
These two methods on JMSContext allow for a context to be created in a "unspecified" sessionMode.
JMSContext createContext()
/Creates a JMSContext with the default user identity and an unspecified sessionMode./
JMSContext createContext(String userName,String password)
/Creates a JMSContext with the specified user identity and an unspecified sessionMode./
What is the semantics of this mode? Can this be tightened up to be one of the valid session modes?
*Context creation in the new API - confusing method calls*
The new API offers two different methods to create a context. The subtle difference in the behavior of these two methods
might not be obvious to the user. Can the API be changed to make the distinction between these two methods more explicit?
Consider creating two sessions from the same connection. In the new API, the first session (context) is created by
Context firstContext = connectionFactory.createContext("user", "passord", JMSContext.CLIENT_ACKNOWLE
To create the second session (context) using the same connection, one has to use a different method call; the context
has to be created using the previously created Context and not the ConnectionFactory
Context secondContext = firstContext.createContext(JMSContext.CLIENT_ACKNOWLEDGE)
Using the first method call results in the creation of a new connection and a new session. The old API, by virtue of
having separate Connection and Session classes, made this distinction obvious to the user of the API.
*Setting a CompletionListener on a JMSMessageProducer - Asymmetric API*
The method to set a CompletionListener on a JMSMessageProducer is different than that for a MessageProducer. Can both
the methods be made symmetric?
When using a MessageProducer, the asynchronous send callback has to be set on per send basis
send(Destination destination, Message message, CompletionListener completionListener)
But when using a JMSMessageProducer, the callback can be set once on the producer
setAsync(CompletionListener completionListener)
Given that old and new APIs are intended to be "parallel"/"equivalent" APIs, it might help to make the method calls as
symmetric as possible.
In this case, both JMSMessageProducer and MessageProducer can allow setting a CompletionListener during creation and
during send.
*Delivery Delay - Relationship to JMSExpiration*
The specification does not describe the behavior when the message delivery delay and the expiration are contradictory.
Specifically, the send method should throw an exception, if the message's delivery delay is greater than the message's
expiration (time to live). (i.e JMSDeliveryTime cannot be greater than JMSExpiration).
*Delivery Delay - Unresolved issue*
From the specification
/
There is an unresolved issue regarding the delivery of messages to topics which have a delivery delay specified. This is
whether the decision to add a message to a subscription (whether durable or non-durable) should be made (a) when the
message reaches its delivery time or (b) when the message is sent./
We agree that this is an edge case. But we would prefer option (a) as it closely mirrors the publisher's intent. i.e If
a publisher intends for a message to be available for consumption 30 minutes from now, consumers who are currently not
connected but who connect to the broker 30 minutes from now should be able to receive the message.
*Disallow white space in subscription names
*
JMS 1.1 did not define what characters were valid in a durable subscription name but JMS 2.0 defines a minimum set of
characters that must be valid in a durable or non-durable subscription name and supported across all providers.
Whitespace is not in the list of valid identifiers but being a white list, it might still be allowed by JMS providers.
Single/multiple leading/trailing white spaces in durable names cause operational problems which are difficult to
diagnose and troubleshoot. e.g Accidental addition of a trailing white space results in a completely new durable being
created.
Can white space be disallowed in subscription names?
*JMSXDeliveryCount - Clarify prefetch behavior
*
Some JMS providers, increment the delivery count on message prefetch. e.g A message which has been prefetched (by the
client library) 5 times will have a JMSXDeliveryCount of 5 even though the message was actually delivered to the client
(from a receive call) only once. This results in incorrect poison message handling.
Can the specification be explicit the JMSXDeliveryCount should be incremented only if the message has been returned from
a receive call?
*Security- Kerberos authentication
*
Can JMS standardize on an authentication scheme like Kerberos? (SASL with Kerberos will be more flexible).
We realize that this might not be possible for JMS 2.0, but will be good feature to have in future versions.
_*Typos
*_
*Non-durable subscriptions*
Refer: JMS_SPEC-40, Section 6.11, Pg 69. The last paragraph (bullet point) should read
/A shared durable subscription is identified by name and an/
instead of
/A shared non-durable subscription is identified by name and an/
*Delivery Delay*
Refer: Section B.5.8, Pg 163. The second paragraph of section B.5.8 should read
/A new section 4.12 "Delivery delay" and a corresponding new section/
instead of
/A new section 4.13 "Delivery delay" and a corresponding new section/