Hi Nigel,
Sorry if I was not clear before. I do agree with option (b): messages
should be added to a subscription when sent.
> 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'm happy that this is fair. Whilst I think it's important that there is
a way to determine that messages are present in the system but not
eligible for delivery, I don't like the idea of bloating the API of the
existing QueueBrowser for the sake of this feature.
The placing of this feature in
http://java.net/jira/browse/JMS_SPEC-59
thus seems to be a good location for such a feature.
Nick
On 07/09/2012 10:54, Nigel Deakin wrote:
> 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
>>
>>