Hi all,
We've been using LVQs from our JMS clients and while they work well
enough, the way we're going about feels a little clunky. The process
we use breaks down as:
- Declare a LVQ with the NO_BROWSE option set for the cache
- Declare a second (non-lvq) to receive real-time updates (likely on a
fanout exchange)
- clients connect to the second queue but don't start consuming msgs yet
- clients then connect to the LVQ and browse the entire thing for the
'snapshot' state
- they then start consuming from the fanout queue and have nothing
more to do with the LVQ
- producers send msgs to both queues
This gives us a way of having multiple clients receive a snapshot when
they start up, and receive additional updates afterwards. It just
feels like we're doing too much work. I guess what I had in mind when
I first heard about LVQs was more of a broker-side key/value cache,
with an efficient way of accessing it from a client. What we'd really
like is a way for clients to say 'give me the last value for key x',
have that call return in a short amount of time (hash-based), and do
it non-destructively (ie, multiple clients could do this and not
remove the msg for other clients). Currently the jms QueueBrowser
implementation doesn't work like that, which is why we've ended up
with the above workaround. (aside thought: perhaps an LVQ in
conjunction with a fanout exchange might be of some use?)
Have I just been completely blind and missed something obvious, or is
this the way it works today? If so, are there any thoughts around
providing something more 'LVQ-oriented' vs 'JMS-oriented'? For
something like this we wouldn't feel strongly about sticking to JMS,
although using a selector on a QueueBrowser would seem an obvious fit.
Thanks very much,
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
