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> 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> 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://clebertsuconic.blogspot.com