qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Crist" <colincr...@hermesjms.com>
Subject RE: [java] Question on implementing queue browsing
Date Wed, 06 Dec 2006 15:59:42 GMT
I'm not sure how to help from the AMQP side of things as I don't know the
protocol well enough so here are some general comments thay may or may not
be helpful
0. Minimal or zero overhead.
1. A queue browse is best effort - it does not reflect what a consumer would
see if they were to read it at that time as that would imply locking to get
a transactionaly intact image of the queue.
2. It should show messages that have been delivered but not
3. It should stream messages out to the browser from the head down taking
into account (2).
4. It should not collect the entire queue image before sending. JBossMQ does
this and it ain't nice as it takes ages for a big queue as you can imagine
(its why Hermes lets you browse using a consumer that does not ack and this
sux due to the side affects on real consumers)
5. Using a queue browser to see whats in a queue and then trying to use
those message ids in a selector does not mean the message will still be
there. Obvious but a common misconception.
6. In the topic domain a similar support is needed to browse messages
waiting for a duable subsription as its really just a queue - and in AMQP's
case I beleive that's actually the case so support it for durable
subscriptions too.
7. Cursors are interesting. When Hermes browses a queue and then a user does
a refresh it compares message ids from the previous browse and then updates
the Swing models appropriately so avoiding too much screen flicker. A cursor
would have a potentially longer lifetime (e.g. based on next-previous
buttons in a browser) and in the absense of any transational co-ordination
you would not get a good idea as to what really happening.  The JMS browse
semantic of head to tail message reading is simple and without any
compelling use-case I'd stick with it.
8. Persistent messaging != database. Another common gotcha. 
9. Selectors should be server side. WebSphereMQ for example does them client
side leading to extra traffice in a queue browse and shameful locking
problems with a real message consumer when there are many consumers. Imagine
it - pre-fetch 500 messages so no other consumer can take them, run the
selector and only release those not matched on a commit so another consumer
can do the same whilst the real consumer waits and waits and waits.... I did
this once and still shudder at the woes it caused. Not a queue brower issue
this of course.
10. No duplicates. 
Its been a while since I've had to digest the JMS spec but I don't thing the
above are against its spirit. For example  a queue browser with a topic URL
encoding the subscription id could work, of course you could do this via JMX
or a semantically AMQP correct java binding.
I guess if i was implementing it, I'd let the queue change under me and
steam out a best effort of its content without duplicates. You can always
get cleverer later if needs demand.
If anyone has specific questions I'd be glad to throw in further
btw hat Mule browse thing is weird.


From: John O'Hara [mailto:john.r.ohara@gmail.com] 
Sent: 05 December 2006 20:25
To: qpid-dev@incubator.apache.org
Cc: Colin Crist
Subject: Re: [java] Question on implementing queue browsing

I've asked Colin Crist if he'd mind sharing any ideas about how an idea
browser would work, given his work on HermesJMS...

Colin :-) ?

MULE uses queue browsing like this:

Which implies it had better construct quickly, since they are likely to be
used as a non-blocking poll of a sort.


On 05/12/06, Carl Trieloff <cctrieloff@redhat.com> wrote: 

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.


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.


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