[
https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997364#comment-12997364
]
Gordon Sim commented on QPID-2104:
----------------------------------
Revision 1069322 adds the desired implementation. The older behaviour is still
there for backward compatibility though we should deprecate and remove it
eventually. To get the new behaviour you specify the key to use via custom
argument 'qpid.last_value_queue_key' (as for Java broker). This is all that is
needed to turn on an LVQ. The older arguments without this new key argument
will give the legacy behaviour.
Note: this implementation does not force all consumers to be browsers (may
revisit that decision at some point).
> Improved LVQ implementation
> ---------------------------
>
> Key: QPID-2104
> URL: https://issues.apache.org/jira/browse/QPID-2104
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Gordon Sim
> Assignee: Gordon Sim
> Fix For: 0.9
>
>
> My view of what ideal 'LVQ' behaviour would 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. the consumers are always non-competing.
> Rob Godfrey also points out that if subscribers fall behind they need only be
> sent the latest for every key (i.e. any superceded values can be skipped).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
