On 10 July 2012 at 11:24 Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> 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).
Yes this is sensible. (b) sounds suitable.
>
> 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.
>
> ...
>
I think the update looks good.
> 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."
>
I would like to propose that there be some additional API call or mechanism for
browsing/knowing about messages which exist in a Subscription that are not yet
eligible for delivery do to a delayed delivery time. Otherwise we can end up in
the situation where resources are consumed by the system but all API calls state
that the server holds no resources.
> 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.
Yes I agree.
Nick