Skip to main content

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

  • From: "John D. Ament" <john.d.ament@...>
  • To: jsr343-experts@...
  • Subject: [jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)
  • Date: Wed, 16 Jan 2013 13:45:28 -0500
  • List-id: <jsr343-experts.jms-spec.java.net>

Hi Nigel,

I think mine and Rudiger's opinions are very close (Rudiger please let me know if you disagree).  Nick's approach though does make sense however I think a fully fledged narrowing API may be too late at this time (for example, apply selectors, where JMSXDeliveryCount > 1, etc).

My response though was primarily based on the existing API documentation's approach that the contents of the browser need not be a snapshot, so messages removed from the queue may still appear here.

Therefore I agree w/ (b) with the caveat that we also think about some kind of queue browser filter API for JMS 2.1.

John


On Wed, Jan 16, 2013 at 1:28 PM, Nigel Deakin <nigel.deakin@...> wrote:
(Note for the busy: this email proposes a spec change, see third paragraph from the bottom)

In Appendix A "Issues" in the draft spec, section A.3.1 "Delivery delay" describes two issues. This email relates to the second, which is described as follows:

-----------------------------------------------------------------------------
Delivery delay is a new feature added in JMS 2.0 and is described in section 4.12 "Delivery delay".

[first issue snipped]

In addition there is an unresolved issue regarding the behaviour of a QueueBrowser. In this specification, section 5.9 "QueueBrowser" has been updated to state that "a message must not be returned by a QueueBrowser before its delivery time has been reached." However there were differing views on this within the JMS 2.0 expert group and further views are invited.
-----------------------------------------------------------------------------

So the question we need to review is whether a QueueBrowser should return messages whose delivery time has not been reached. There are two choices:

(a) a message must not be returned by a QueueBrowser before its delivery time has been reached

(b) a QueueBrowser will return messages on a queue irrespective of whether their delivery time has been reached.

When we discussed this back in July I proposed (a). I said that a QueueBrowser should behave similarly to an ordinary consumer, and so only return messages which were eligible to be delivered. This is what the spec current says.

However there was definitely less than wholehearted support for this from the expert group.

Rüdiger zu Dohna preferred (b). He wrote "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."

Nick Wright was ambivalent: He wrote "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."

John Ament wrote (when he reviewed the public draft in December) that "I feel like this shouldn't be a requirement for the browser - it should show all available messages on a queue regardless of ready to deliver or not."

Although these three comments also propose additional functionality, they are all consistent in saying that it was important to be able to find out all the messages on the queue, including those which have not yet reached their delivery time.

SPEC CHANGE: Given these comments, and the fact that don't have a *very* strong view on which option we adopt, I would like to suggest that we change the behaviour required by the spec from (a) to (b). This means that a QueueBrowser will return messages on a queue irrespective of whether their delivery time has been reached.

Is everyone happy with this change? Please give your views.

This discussion also showed a definite interest in better administrative or management API to allow messages on a queue or topic to be viewed and perhaps deleted. This is out of scope for JMS 2.0, but is definitely something we should discuss for JMS 2.1.

Nigel



[jms-spec users] [jsr343-experts] Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Nigel Deakin 01/16/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

John D. Ament 01/16/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Robert Davies 01/16/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Clebert Suconic 01/16/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Nigel Deakin 01/17/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Clebert Suconic 01/17/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Nigel Deakin 01/17/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Rüdiger zu Dohna 01/17/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Clebert Suconic 01/17/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Rüdiger zu Dohna 01/18/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)

Clebert Suconic 01/18/2013
 
 
Close
loading
Please Confirm
Close