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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 3:12 PM To: [email protected] 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.
