Skip to main content

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

  • From: Robert Davies <rajdavies@...>
  • 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 21:34:02 +0000
  • List-id: <jsr343-experts.jms-spec.java.net>

My very strong preference is to keep option a) - a message is not returned by 
a QueueBrowser before its delivery time has been reached - it could add to a 
lot of confusion when comparing results returned from a QueueBrowser to an 
active consumer - and it will be hard to implement without in existing JMS 
implementations without adding complexity.

My preference would to be cover messages that are yet to be delivered in a 
management API - or consistent set of MBeans or MXBeans for JMS 2.1.

Rob

On 16 Jan 2013, at 18:28, 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