Skip to main content

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

  • From: John Archbold <jarchbol@...>
  • To: <jsr343-experts@...>
  • Subject: [jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 2: behaviour of QueueBrowser)
  • Date: Thu, 7 Feb 2013 13:25:43 -0800
  • List-id: <jsr343-experts.jms-spec.java.net>

Hi Nigel,

Agree. I am in favor of option (a).

Thanks,
John Archbold



On 2/1/2013 7:38 AM, Nigel Deakin wrote:
Now let us consider this unresolved issue:

On 17/01/2013 12:03, 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.)


Since then Rüdiger reiterated his "strong" support for (b).

I also re-read John Ament's email of 16 Jan 2013 in which he said that although "mine and Rudiger's opinions are very close", he also said that "I agree with (b) with the caveat that we also think about some kind of queue browser filter API for JMS 2.1.".

I think we do need to make a decision here. Remember this is a side-affect of the delivery delay feature, not a new feature in itself.

I think that we are all agreed that the ideal solution is to provide both (a) and (b). This allows the application to decide what information they want. However we are rather limited by the existing QueueBrowser interface so this would require a completely new API.  Since that API would probably want to offer other features such as topic and subscription browsing this is a significant effort which will need to wait until JMS 2.x.

The requirement for an "new" queue and topic browser is recorded as
http://java.net/jira/browse/JMS_SPEC-59
I have already added the requirement to optionally return "future messages" to that issue.

In the meantime we are stuck with the limited QueueBrowser API and have to define what it does. I think we shouldn't leave this undefined unless we are really at loggerheads. So I propose we go with the majority of views expressed and go for (a) - a message must not be returned by a QueueBrowser before its delivery time has been reached. Which is what the spec says now.

We can then add support for (b) in JMS 2.x.

Nigel










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

Nigel Deakin 02/01/2013

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

John Archbold 02/07/2013
 
 
Close
loading
Please Confirm
Close