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