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 00:12:46 GMT
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.
>
>
>

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