Dear All,
I'd like to get the definition of delivery delay completed, partly to allow work on the adding this feature to the
reference implementation to be finished and partly because I'd like to get this issue written-up for the Public Draft.
So please read on.
As usual, the updated spec can be found at
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
and the updated API docs at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html
On 16/07/2012 17:39, Nigel Deakin wrote:
> Thank you Rüdiger and Nick for your comments.
>
> On 10/07/2012 11: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).
>
> My preference was (b)
> Rüdiger supported (a)
> Nick supported (b) (or at least didn't object to it).
>
> Any more views? I don't think there's a consensus on this yet.
>
> If a clear consensus doesn't emerge then my preference would be for me to pick one of the options (still probably b) and
> make the appropriate spec changes. However in addition I would specifically list this in an appendix of the the next
> formal draft of the spec as an unresolved issue. This gives the RI implementers something to work on, but keeps the
> issue alive whilst we seek further views and discuss this further. Having a proposal written into the spec also gives
> people something specific to read, and to object to.
This discussion didn't go any further so I am going to do what I proposed, which is to choose option (b). I have
therefore updated the draft spec section 4.12 "Delivery delay" to state:
"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."
As promised above, however, I have listed this as an unresolved issue in section A.3. "Unresolved issues in the JMS 2.0
Public Draft" This means that we are specifically inviting views during the next formal draft. A new subsection A.3.1
"Delivery delay" discusses the two options and invites comments.
>
>> 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."
>
> Rüdiger disagreed, and thought that the messages returned by a QueueBrowser should include messages whose delivery time
> had not been reached.
>
> Nick, I think, supported my proposal but added that a new variant of QueueBrower was needed which would return messages
> whose delivery time had not been reached.
>
> Again, more views please. Again, a clear consensus doesn't emerge then I suggest we follow the same approach for this:
> I'll pick an option, write it in the spec and list it in the appendix as an unresolved issue.
Again this discussion didn't proceed much further. There is a clear desire amongst those EG members who expressed an
opinion to provide a more extensive API to allow state a queue to be examined, and this should include an option to
browse the messages on a queue which are not eligible to be delivered because their delivery time has not been reached,
and to remove messages from the queue. We already have an open issue JMS_SPEC-59 which captures some of the requirements
for such a feature, and I have now updated it to add this requirement.
In the meantime, however, we still need to define how the *existing* QueueBrowser behaves with such messages. I have
therefore decided to go ahead with my proposal that the QueueBrowser should only return messages whose delivery time has
been reached and which are eligible to be delivered immediately. This is consistent with the common (though not
explicitly spec-defined) behaviour of QueueBrowsers which is to not return messages which are currently behaving in a
local or XA transaction, or messages which have been delivered to a customer and have yet to be acknowledged.
I have updated section 5.9 "QueueBrowser" and the javadoc comment for the QueueBrowser interface to add "A message must
not be returned by a QueueBrowser before its delivery time has been reached."
I have also listed this as an unresolved issue in the draft specification (in section A.3.1 as above).
Nigel
>
> If we were to take up Nick's suggestion, what would the API look like? Currently there are two methods on Session to
> create a QueueBrowser
>
> QueueBrowser createBrowser(Queue queue)
> QueueBrowser createBrowser(Queue queue, java.lang.String messageSelector)
>
> with equivalent methods on JMSContext.
>
> We could add a third method on each:
>
> QueueBrowser createBrowser(Queue queue, java.lang.String messageSelector, boolean showFutureMessages)
>
> where the showFutureMessages parameter means the QueueBrowser should include messages whose delivery time has not yet
> been reached.
>
> Comments please? Is this a useful method, or does it simply bloat the API?
>
> Nigel
>
>