Skip to main content

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

  • From: Rüdiger zu Dohna <ruediger.dohna@...>
  • To: "jsr343-experts@..." <jsr343-experts@...>
  • Subject: [jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)
  • Date: Thu, 17 Jan 2013 21:01:29 +0100
  • Accept-language: en-US, de-DE
  • Acceptlanguage: en-US, de-DE
  • List-id: <jsr343-experts.jms-spec.java.net>

When I think about the use-cases for a QueueBrowser, everything that comes to 
my mind is related to queue management. As Nigel points out, non-committed 
sends and delivery are not visible, but still what a user probably would 
expect, as the same happens in databases as well.

I can understand that depending on the data structures used in the JMS 
provider may make it difficult to implement, but what reasons are there on 
the JMS users side?

Robert writes: "it could add to a lot of confusion when comparing results 
returned from a QueueBrowser to an active consumer". I think the opposite is 
true: If I look at the messages in a QueueBrowser, I'd expect to see all 
messages that are not yet consumed... either because the consumers didn't 
come around yet, or because their delivery delay stops them. To me this seems 
very natural.

Are there other reasons for (a)?

I support Johns suggestion to standardize on a syntax for a delay message 
selector for QueueBrowser in 2.1 (it wouldn't make any sense in normal 
message selectors, would it?).

So I'm strongly for (b). But if we can't find consensus on this issue, maybe 
we'd have to leave it up to the implementors and fix it in 2.1? Far from the 
perfect solution, I know, but better than delaying delaying (pun intended).


Rüdiger

On 2013-01-17, at 13:03, Nigel Deakin <nigel.deakin@...> wrote:

> Thanks! Since I proposed switching from (a) to (b) there has been a surge 
> in support for (a).
> Here's the balance of views I have received:
> 
> * In favour of (a) a message must not be returned by a QueueBrowser before 
> its delivery time has been reached
> 
> Me (initially), Clebert, Rob ("strong" preference), Tom (directly to me)
> 
> * In favour of (b) a QueueBrowser will return messages on a queue 
> irrespective of whether their delivery time has been 
> reached.
> 
> John A, Rüdiger (in 2012), Nick W (in 2012) (All gave caveats which I'm not 
> repeating here)
> 
> Note that I am really trying to establish views and seek a consensus rather 
> than formally counting votes. I am certainly 
> interested in the views of both Clebert and Rob - who are from the same 
> company but "represent" different JMS providers. 
> Here at Oracle we have two reps as well, with my colleague Tom bringing his 
> experience of Weblogic and other Oracle JMS 
> providers to suppose my experience of GlassFish. Tom's told me directly 
> that he is in favour of (a).
> 
> As I said, I would like to seek consensus. I think we are all agreed that 
> we need better queue (and especially topic) 
> browsing functionality, and we have a growing list of suggestions in 
> http://java.net/jira/browse/JMS_SPEC-59. We will ;
> definitely consider this for JMS 2.1. If we go for (a) after all then it 
> would be on the basis that additional features 
> should be added in 2.1.
> 
> (Incidentally, one of the arguments made for (b) is that it gives a more 
> accurate indication of the resource usage of a 
> queue. However it has been pointed out to me that a queue browser doesn't 
> do that even now and it should not be used for 
> that purpose. For example a QueueBrowser is free to ignore messages which 
> have been added to the queue in a transaction 
> which is not yet committed, even though these occupy resources. And it is 
> free to ignore messages which have been 
> delivered but which have not yet been acknowledged or committed, even 
> though they have not yet been removed from the queue.)
> 
> Any more views?
> 
> Nigel
> 
> 
> 
> On 16/01/2013 21:40, Clebert Suconic wrote:
>> I and Rob share the same voting.. but I also have strong preferences about 
>> a.
>
>
>> On Wed, Jan 16, 2013 at 3:34 PM, Robert Davies <rajdavies@... 
>> <mailto:rajdavies@...>> wrote:
>
>>    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@... 
>> <mailto: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
>
>
>
>
>> --
>> Clebert Suconic
>http://community.jboss.org/people/clebert.suconic@...
>http://clebertsuconic.blogspot.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[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