| Summary: | LVQ behaviour enhancement needs to be documented | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Petr Matousek <pematous> |
| Component: | Messaging_Programming_Reference | Assignee: | Joshua Wulf <jwulf> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | Development | CC: | chetan, gsim, iboverma, jskeoch, lbrindle, lcarlon, pmoravec, tross |
| Target Milestone: | 2.2 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-09-20 03:13:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Petr Matousek
2011-05-25 14:50:20 UTC
Insufficient time for inclusion in 2.0. RFE for 2.1, set 'requires_release_note' flag if a mention is required in the Release Notes for 2.0 Setting NEEDINFO from reporter, please feel free to pass on to someone more appropriate. Will be addressed after 2.1. LKB Gordon Sim confirmed that he will provide some description of the new LVQ functionality. Please contact Gordon for informations needed. Some knowledge can be also gained from in Bug 632000. I'd replace the 'last value queues' section in chapter 3 with something like: Last value queues retain only the last message for each value of a particular message property. To enable this behaviour, choose the message property on which to key messages using the qpid.last_value_queue_key argument when creating the queue. For example, lets assume a last value queue is created keyed on property 'ticker'. Messages can be sent with different values for the 'ticker' property. Only the last message for each ticker will be held in the queue. You can subscribe as a browser to such a queue in order to get the latest set of messages for all tickers, as well as any future updates. Providing all subscribers are browsing (and not dequeing messages), they can all share the same last value queue instance. Of course the old behaviour as currently documented is still supported and if desired can be kept in in some form. New content upstream related to this issue: http://qpid.apache.org/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/ch01s06.html Last Value Queue description: http://deathstar1.usersys.redhat.com:8080/TopicIndex/Books/editor/preview.html?skyneturl=http://skynet.usersys.redhat.com:8080/TopicIndex&topicid=8099 Last Value Queue Python demonstration: http://deathstar1.usersys.redhat.com:8080/TopicIndex/Books/editor/preview.html?skyneturl=http://skynet.usersys.redhat.com:8080/TopicIndex&topicid=8393 Last Value Queue Command-line demonstration: http://deathstar1.usersys.redhat.com:8080/TopicIndex/Books/editor/preview.html?skyneturl=http://skynet.usersys.redhat.com:8080/TopicIndex&topicid=10133 Staged build coming soon. (Can't push to stage atm) http://deathstar1.usersys.redhat.com:8080/TopicIndex/Books/Messaging_Programming_Reference/index.html#Last_Value_Queue_Example Released for MRG 2.2 |