qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: [java] Question on implementing queue browsing
Date Wed, 06 Dec 2006 09:33:21 GMT
Bingo.

There's nothing in the JMS spec, from what I recal of it, that would prevent
browse being implemented as a "snapshot" view of the queue at the point
where the browse is constructed.
At which point, MULE's code would fail.

I do agree it is being used like a kind of select, and obviously had some
advantage on the particular JMS it was used with.

If JMS had message peek, it wouldn't be necessary.

John

On 06/12/06, Tim Fox <tim.fox@jboss.com> wrote:
>
> Problem is, there is no guarantee a JMS server's implementation of
> browsing accurately reflects what is in the queue at any particular
> time, otherwise you would have to lock the whole queue (See jms 1.1. spec)
>
> So don't use it for anything where you can't cope with missing messages
> / duplicates.
>
> John O'Hara wrote:
> > Nope Browsing isn't there, yet.
> > Protocol proposal required.
> >
> > The MULE use case threw me - I went and looked a the code in the link
> > and it
> > strikes me a wierd too.
> >
> > I also initially thought that taking a snapshot would make sense, and
> > treating it from an AMQP viewpoint as kind of a temporary "snapshot"
> > private
> > / virtual queue.  Then you could use normal protocol dequeues to read
> it.
> > Seems neat.
> >
> > But the Mule usage is something much more dynamic; possibly illegal, and
> > certainly not portable.
> >
> > I'd like to see more examples of what use cases there are for browse,
> aside
> > from admin tools.
> > Peeking at the next message would seem to be another one, but JMS doesnt
> > have message peeking abilities (unlike some other middleware).
> > Is peek a browser, and a look at the first message? (this is what that
> MULE
> > plugin is doing)
> > Does the browser get live updates, like a dirty read on a DB?  (e.g. I
> can
> > read it now and its empty, but try again in 2 mins and suddenly my
> > enumerator has more content?
> >
> > I'm kind of thinking this is the case, having read the browse JMS API
> docs.
> > It returns the messages in the order that would be *next* received by
> the
> > client...
> >
> > Anyone want to shed light on which semantic is right?
> > John
> >
> > On 05/12/06, Das, Kapali Tejeswar <tejeswar.das@iona.com> wrote:
> >>
> >> Carl,
> >>
> >> I didn't find queue browsing mentioned in the AMQP 0.8 spec. That
> >> explains the fact that there is no implementation in Qpid to browse the
> >> messages in the queue.
> >>
> >> My work is essentially to implement the JMS QueueBrowser feature that
> >> would return a java.util.Enumeration which the caller uses to browse
> the
> >> messages. JMS doesn't provide any guideline as to how it should be
> >> implemented. Ideally, we may want to take the snapshot of all the
> >> messages in the queue and present to the user. That way it (browsing)
> >> won't have any effect on any other threads that are actively
> >> producing/consuming messages.
> >>
> >> In order to build the snapshot of the messages, we need to be able to
> >> read a message without removing it from the queue. SynchronousQueue
> >> doesn't support this.
> >>
> >> Any feedback is greatly appreciated.
> >>
> >> Thanks and regards
> >> Tej
> >>
> >>
> >> -----Original Message-----
> >> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
> >> Sent: Tuesday, December 05, 2006 3:12 PM
> >> To: qpid-dev@incubator.apache.org
> >> Subject: Re: [java] Question on implementing queue browsing
> >>
> >>
> >>
> >> Tim Fox wrote:
> >> >
> >> >
> >> > Das, Kapali Tejeswar wrote:
> >> >> I am currently working on implementing the JMS queue browsing
> >> >> functionality. Qpid uses java.util.concurrent.SynchronousQueue for
> >> its
> >> >> internal queue for enqueing and dequeing messages. This class
> doesn't
> >> >> allow to peek/browse messages in the queue. It only has methods to
> >> put a
> >> >> message or get a message (with a timeout).
> >> >
> >> > Right. Also, for JMS, you'll need to implement some kind of priority
> >> > queue, which SynchronousQueue won't handle.
> >>
> >> Tej,
> >>
> >> In most use cases queue browsing can be counter productive for clients
> >> that want throughput or guarantees so we should not penalize the
> >> non-browsing and priority use cases. I also think that we might need to
> >> add to specification to complete this as I don't think it can be done
> on
> >>
> >> 0-8 without being very hacky ...  Have you been able to map this
> through
> >>
> >> the current specification or is the starting point to define a peek cmd
> >> needed in the spec that we can provide to the working group. The
> >> interaction pattern and semantics between peeking the queue and
> messages
> >>
> >> being removed needs also be defined.
> >>
> >>
> >> Carl.
> >>
> >>
> >>
> >
>
> --
> Tim Fox
> JBoss Messaging Technical Lead
> JBoss - a division of Red Hat
> T: +44 2088006768
> M: +44 7957983205
> E: tim.fox@jboss.com tim.fox@redhat.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message