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
>
>
>
>
>
>
>