The biggest source of confusion among JMS users is mixing up databases and
message systems.
Aberrations like store a message and use a Browser to retrieve the
"data"..... That's the biggest problem and anti-pattern of all in
messaging.
Message systems are optimized for fast message delivery and not data
recovery!
So, I don't like the Database comparison there. In fact you don't even need
a database to backbone a message systems.
Anyway.. I feel like it should be left to the implementation to decide
what's the best or I would keep things the way the are with Browsers on
this semantic.
On Thu, Jan 17, 2013 at 2:01 PM, Rüdiger zu Dohna
<ruediger.dohna_at_1und1.de>wrote:
> When I think about the use-cases for a QueueBrowser, everything that comes
> to my mind is related to queue management. As Nigel points out,
> non-committed sends and delivery are not visible, but still what a user
> probably would expect, as the same happens in databases as well.
>
> I can understand that depending on the data structures used in the JMS
> provider may make it difficult to implement, but what reasons are there on
> the JMS users side?
>
> Robert writes: "it could add to a lot of confusion when comparing results
> returned from a QueueBrowser to an active consumer". I think the opposite
> is true: If I look at the messages in a QueueBrowser, I'd expect to see all
> messages that are not yet consumed... either because the consumers didn't
> come around yet, or because their delivery delay stops them. To me this
> seems very natural.
>
> Are there other reasons for (a)?
>
> I support Johns suggestion to standardize on a syntax for a delay message
> selector for QueueBrowser in 2.1 (it wouldn't make any sense in normal
> message selectors, would it?).
>
> So I'm strongly for (b). But if we can't find consensus on this issue,
> maybe we'd have to leave it up to the implementors and fix it in 2.1? Far
> from the perfect solution, I know, but better than delaying delaying (pun
> intended).
>
>
> Rüdiger
>
> On 2013-01-17, at 13:03, Nigel Deakin <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. 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>> 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>> 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
>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com