Agree. I am in favor of option (a).
On 2/1/2013 7:38 AM, Nigel Deakin
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
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
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
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
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.