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 <[EMAIL PROTECTED]> 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 <[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. >> >> >> > -- Tim Fox JBoss Messaging Technical Lead JBoss - a division of Red Hat T: +44 2088006768 M: +44 7957983205 E: [EMAIL PROTECTED] [EMAIL PROTECTED]
