I refer to
http://java.net/jira/browse/JMS_SPEC-44 (New API to specify delivery delay)
We added this to the spec and javadocs quite a long time ago. I'm pleased to report that implementation work for the RI
is currently in progress. The implementer of this feature has been asking me how delivery delay works for topics. I
think this is something the spec needs to clarify. A small clarification is also needed for QueueBrowser.
The key issue 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.
Note that this is a question about deciding which subscriptions a message is added to, not about when the message would
actually be delivered. In both cases the message wouldn't be delivered to a consumer until the delivery time has been
reached.
If we adopted (a) this would require the JMS provider to keep all messages in the server until their delivery time is
reached, even if there were no durable or non-durable subscriptions in existence. This might even be needed for
non-persistent messages. Adopting (b) does not require this and by not requiring a message to be held separately from a
subscription is closer to the way in which JMS providers work now. My feeling is that forcing a JMS provider to
implement (a) would potentially add a significant burden simply to cater for an unimportant edge case. I therefore
propose we adopt (b).
I have drafted the following updated text for section 4.12 to describe this. We would update the javadocs similarly.
(I've also dropped the phrase "visible on the target destination" which is unclear and unnecessary)
-----------------------------------------------------------------------------------------------
4.12. Delivery delay
A client can specify a delivery delay value in milliseconds for each message it sends. This value defines a message
delivery time which is the sum of the message's delivery delay and the GMT it is sent (for transacted sends, this is
the time the client sends the message, not the time the transaction is committed).
A message's delivery time is the earliest time when a JMS provider may deliver the message to a consumer. The provider
must not deliver messages before the delivery time has been reached.
If a message is published to a topic, it will only be added to a durable or non-durable subscription on
that topic if the subscription exists at the time the message is sent and continues to exist at the time the specified
message delivery time is reached.
For more information on message delivery delay, see Section 3.4.13 "JMSDeliveryTime".
-----------------------------------------------------------------------------------------------
What do you think? Please express your views by Friday 13th July.
...
Separately, I think we need to clarify the behaviour of a QueueBrowser when delivery delay is used. I think our approach
should be that the QueueBrowser should only return messages which are eligible to be delivered immediately. I therefore
propose that this be clarified to state that "a message must not be returned by a QueueBrowser before its delivery time
has been reached."
Note that JMS 1.1 states that whether an Enumeration returned by a QueueBrowser is a static snapshot, or is dynamically
updated as new messages arrive or as messages expire, is provider dependent. I suggest that for consistency the same
should apply to delivery delay.
Nigel