I didn't to be harsh.. I was just making a point about the fact that we
optimize message delivery, consistently and transactionally.
Having this kind of thing as a requirement would obligate us to require
data access of some sort when the message is not yet delivered. That would
imply into some consequences of design changes on implementors, and I don't
think that would be a desirable thing for this spec IMHO.
On Fri, Jan 18, 2013 at 1:24 AM, Rüdiger zu Dohna
<ruediger.dohna_at_1und1.de>wrote:
> Clebert,
>
> Sorry, I wasn't clear enough. I didn't want to compare messaging systems
> to databases in general. I only wanted to point out that both are
> (generally) transactional systems. And people are quite aware about what
> that implies: When things change, you may not yet see it.
>
>
> Rüdiger
>
> On 18.01.2013, at 00:17, Clebert Suconic <clebert.suconic_at_gmail.com>
> wrote:
>
> > 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
>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com