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.|
Comments on the Public Draft
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?
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.
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
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.
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
A shared non-durable subscription is identified by name and an
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
A new section 4.13 "Delivery delay" and a corresponding new section
[jms-spec users] [jsr343-experts] JMS 2.0 PR: Feedback from Goldman Sachs