On 09/14/2009 10:56 PM, Andrew Wright wrote:
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'?
I think clunky is a fair description of the current capabilities and I
think we can improve on that.
My view of what ideal 'LVQ' behaviour whould be like is that the 'queue'
would really be more like a 'topic' where the last message for each key
was always saved. Clients would subscribe to it and receive the last
message published for each key and subsequently any updates (i.e. any
new messages).
I.e. it would do pretty much what you describe, but through a simpler
interaction. The client would just need to 'subscribe' to the 'LVQ'.
I would think that in JMS this would be made available as a Destination
you could create consumers and producers from for normal use. It would
behave more like a JMS topic than a queue though (i.e. consumers would
not compete for messages).
Are there other views or use cases on what it should do?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
