I'd prefer (a), but, as you say, this may impose a significant burden on the providers. Why not leave it unspecified? The providers would be asked to document their behavior, and they may even choose to make it configurable per topic or so.
OTOH I think it's important, that the QueueBrowser should also report waiting messages: We use browsers for tooling, and in that use case, it's even more important to be able to, e.g., cancel messages while they are waiting.
On 2012-07-10, at 12:24, Nigel Deakin 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).
>
> 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