Clebery,
On 17/01/2013 14:50, Clebert Suconic wrote:
> >>>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.)
>
> So you are leaving it with the provider's discretion, depending on the implementation?
That wasn't what I meant (I clearly worded it badly). I was giving an existing example of when a message that was on the
queue wasn't returned by the queue browser. That would support going for (a). I am not currently proposing that we
allow the provider to decide whether to go for (a) or (b).
Nigel
> If I understood it correctly I think it's fair. Changing semantics there could have large affects either way depending
> on how the data structure is implemented.
>
>
> On Thu, Jan 17, 2013 at 6:03 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> 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 <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_at_gmail.com <mailto:rajdavies_at_gmail.com>
> <mailto:rajdavies_at_gmail.com <mailto:rajdavies_at_gmail.com>>> 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_at_oracle.com <mailto:nigel.deakin_at_oracle.com>
> <mailto:nigel.deakin_at_oracle.__com <mailto:nigel.deakin_at_oracle.com>>> 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@jboss.__com
> <http://community.jboss.org/people/clebert.suconic@jboss.com>
> http://clebertsuconic.__blogspot.com <http://clebertsuconic.blogspot.com>
>
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com