You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <qp...@incubator.apache.org> on 2009/09/16 09:35:57 UTC
[jira] Created: (QPID-2104) Improved LVQ implementation
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
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. 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755921#action_12755921 ]
Gordon Sim commented on QPID-2104:
----------------------------------
>From Andrew Wright: "The only other use case I can imagine would be calling into the broker on an ad-hoc basis, supplying a key and being returned the message that currently matches that key, or null if there never was one. That could perhaps be useful in very high update rate scenarios, where you'd want the broker to bear the work of maintaining the queue without making clients receive every (or even every few) messages."
> 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
>
> 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. 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797080#action_12797080 ]
Gordon Sim commented on QPID-2104:
----------------------------------
The property used as the key should ideally be configurable also.
> 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
>
> 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. 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org