Here is the reply I sent to Florian Beaufumé (copied here with permission):
> Florian Beaufumé wrote on 02/09/2012 07:28 AM:
>> ----- JMS -----
>>
>> JMS.1 - There should be a portable way to specify a send delay (I mean in pure JMS, not with EJB timer or other API)
>> to make a message available only after some time. See https://forums.oracle.com/forums/thread.jspa?threadID=2124412
>> for details.
Yes, this will be in the JMS 2.0 early draft (available from the link above)
The JIRA issue to track this is
http://java.net/jira/browse/JMS_SPEC-44
>>
>> JMS.2 - Poison messages handling is unspecified. Non portable application server specific features include: dead
>> letter queue configuration, retry count configuration, resend delay configuration... We need portable solutions. See
>> https://forums.oracle.com/forums/thread.jspa?threadID=2124413 for details.
Yes, this is an important area which JMS doesn't say anything about, and as a result there are many non-standard
facilities. It's hard to retrospectively standardise on something that vendors already support, but we thought that one
small change would make it easier for applications to add their own poison message handling, which is to make support
for JMSXDeliveryCount mandatory. This will be in the JMS 2.0 early draft
The JIRA issue to track this is
http://java.net/jira/browse/JMS_SPEC-42
However I know you are raising a more general requirement, so I have created a new JIRA issue and pasted your
suggestions into it:
http://java.net/jira/browse/JMS_SPEC-72
>>
>> JMS.3 - The number of deliveries of a message sent to a topic is unspecified. See
>> https://forums.oracle.com/forums/thread.jspa?threadID=2124417 for details.
I've logged your suggestion as
http://java.net/jira/browse/JMS_SPEC-73
As you say, JMS doesn't say anything about how messages from a topic are delivered to consumers on clustered application
server instances and I agree that this is an important area where vendors currently do things differently. It is also an
area where some vendors currently deliberately break the JMS spec by allowing multiple connections to have the same
clientID.
I think it is certainly desirable to define more specifically how clustered MDBs should behave when consuming form a
topic (for both non-durable and durable subscriptions), but I think the most important thing is to allow MDBs (and
applications in general) to be able to consume messages from the same topic subscription (non-durable and durable) using
separate threads, possibly running in separate JVMs.
There are several components of this. The first change, and this will be in the early draft, is to remove the need to
set clientID when using durable subscriptions. The second change, and this just missed the early draft, is to allow
multiple consumers to be created on the same durable subscription. This change depends on the first. The third change is
to allow multiple consumers to be created on the same non-durable subscription. This change will entail allowing
non-durable subscriptions to be identified by name.
First change: (in the early draft)
http://java.net/jira/browse/JMS_SPEC-39
Second and third changes: (just missed the early draft, will be in next draft)
http://java.net/jira/browse/JMS_SPEC-40
Now these changes themselves don't define how consumers in clustered application server instances should behave, though
I think it will provide new options for applications to specify the exact behaviour they require. I'll make sure we look
at this in more detail.
The EJB spec doesn't currently specify how you specify a durable subscription name. I have asked the EJB 3.2 expert
group to specify this:
http://java.net/jira/browse/EJB_SPEC-41
(we would probably use this for non-durable subscription names as well)
>>
>> JMS.4 - Durable topic subscription lifecycle for MDB is not specified. See
>> https://cn.forums.oracle.com/forums/thread.jspa?threadID=2124418 for details.
Good comments. I've logged them here:
http://java.net/jira/browse/JMS_SPEC-74
(This may need to be discussed with the EJB 3.2 expert group).
>>
>> JMS.5 - @MessageDriven configuration specification is unclear and non portable.
I noticed this as well, and submitted three issues to the EJB 3.2 expert group:
http://java.net/jira/browse/EJB_SPEC-43
http://java.net/jira/browse/EJB_SPEC-42
http://java.net/jira/browse/EJB_SPEC-41
Please take a look and let me (or the EJB spec lead) know if these address your concerns.
>>
>> JMS.6 - 'clientID' and 'subscription name' should be better defined in the specification.
Can you please expand on this? Is this a reference to MDB config, or a more general comment about client ID and durable
subscriptions?
>> JMS.7 - JMS clustering is completely unspecified. Yet there is a lot to say: first about the load-balancing and
>> fail-over between the JMS producer and the JMS engine, then the load-balancing between JMS engine instances and then
>> the load-balancing between a JMS engine instance and the JMS consumers.
Yes. This is a big area which we haven't gone into so far. What I'd like to focus on is those aspects where the lack of
clarity in the spec prevents users writing portable applications rather that simply trying to make different JMS
implementations offer the same quality-of-service features. So with that in mind, would you like to be more specific
about the kind of things you would like to see in the spec?
(You can make suggestions to me directly, or you can submit them to JIRA directly. As spec lead I have an obligation to
make sure that all JIRA issues are evaluated and considered).
Nigel