qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Java/JMS LVQ interaction
Date Tue, 15 Sep 2009 11:48:08 GMT
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:users-subscribe@qpid.apache.org


Mime
View raw message