Bug 479423 - Correction to LVQ text in Docs
Correction to LVQ text in Docs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Documentation (Show other bugs)
1.1
All Linux
high Severity high
: 1.1.1
: ---
Assigned To: Lana Brindley
Jeff Needle
: Documentation, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-09 09:37 EST by Carl Trieloff
Modified: 2013-10-23 19:12 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-12 00:14:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Carl Trieloff 2009-01-09 09:37:38 EST

    
Comment 1 Carl Trieloff 2009-01-09 09:49:08 EST
Last value queues

The last value queue type causes logically updated versions of previous messages to appear to overwrite the older messages. 

There are two variations of LVQ.
 a.) LVQ
 b.) LVQ NO BROWSE


To use this feature, add a qpid.last_value_queue or qpid.last_value_queue_no_browse for LVQ or LVQ_NO_BROWSE respectively to the arguments of queue declare. The value of the key is user selected for the match and irrelevant beyond providing the key matching. Messages published to the queue then need to specify a value for the qpid.LVQ_key in the headers of messages they publish.

Example:
{
#include "qpid/client/QueueOptions.h"

    QueueOptions qo;
    qo.setOrdering(LVQ);

    session.queueDeclare(arg::queue=queue, arg::arguments=qo);

    .....
    string key;
    qo.getLVQKey(key);

    ....
    for each message, set the into application headers before transfer
    message.getHeaders().setString(key,"RHT");
}

The last value queue uses the value of the qpid.LVQ_key to determine whether a newly published message is an update to an existing message on the queue. If this is the case, the new message will appear to overwrite the older message. A subscriber that requests messages after this has occurred will see only the newer message. 

LVQ specific semantics:

LVQ uses a header for a key, if the key matches it replaces the message in-place in the queue except
a.) if the message with the matching key has been acquired
b.) if the message with the matching key has been browsed
In these two cases the message is placed into the queue in FIFO, if another message with the same key is received it will the 'un-accessed' message with the same key will be replaced

These two exceptions protect the consumer from missing the last update where a consumer or browser accesses a message and an update comes with the same key.

LVQ NO BROWSE semantics:

LVQ uses a header for a key, if the key matches it replaces the message in-place in the queue except
a.) if the message with the matching key has been acquired
In these two cases the message is placed into the queue in FIFO, if another message with the same key is received it will the 'un-accessed' message with the same key will be replaced

Note, in this case browsed messaged are not invalidated, so updates to messages already browsed on a key will be missed. If a new subscription is created the latest values will be seen.
Comment 2 Carl Trieloff 2009-01-09 09:50:09 EST
Please replace the current test in chapter 3 on Last Value Queue with the above expanded version.

thanks
Comment 3 Lana Brindley 2009-01-11 20:15:34 EST
	<formalpara id="form-Messaging_User_Guide-Queues-Last_value_queues">
		<title>Last value queues</title>
		<para>
			The <firstterm>last value</firstterm> queue type causes logically updated versions of previous messages to appear to overwrite the older messages.
		</para>
	</formalpara>
	<para>
		The last value queue uses the value of the <parameter>qpid.LVQ_key</parameter> to determine whether a newly published message is an update to an existing message on the queue. If this is the case, the new message will appear to overwrite the older message. A subscriber that requests messages after this has occurred will see only the newer message.
	</para>
	<itemizedlist>
		<para>
			There are two types of Last Value Queue:
		</para>
		<listitem>
			<para>
				<command>LVQ</command>
			</para>
		</listitem>
		<listitem>
			<para>
				<command>LVQ NO BROWSE</command>
			</para>
		</listitem>
	</itemizedlist>
	<para>
		<command>LVQ</command> uses a header as a key. If the key matches it replaces the message in the queue, unless: 
		<itemizedlist>
			<listitem>
				<para>
					the message with the matching key has been acquired
				</para>
			</listitem>
			<listitem>
				<para>
					the message with the matching key has been browsed
				</para>
			</listitem>
		</itemizedlist>
		 In these cases the message is placed into the queue in FIFO. If another message with the same key is received the message that has not been accessed will be replaced. These two exceptions protect the consumer from missing the last update if a consumer or browser has accessed a message.
	</para>
	<para>
		<command>LVQ NO BROWSE</command> also uses a header for a key. If the key matches it replaces the message in the queue unless the message with the matching key has been acquired. In this case browsed messaged are not invalidated, so updates to messages already browsed on a key will be missed. If a new subscription is created the latest values will be seen.
	</para>
	<para>
		To use this feature, add a <parameter>qpid.last_value_queue</parameter> or <parameter>qpid.last_value_queue_no_browse</parameter> key to the arguments of queue declare. The value of the key is user-selected and used only for key matching. Messages published to the queue then need to specify a value for the <parameter>qpid.LVQ_key</parameter> in the headers of messages they publish.
	</para>
	<example id="exam-Messaging_User_Guide-Queues-Setting_the_LVQ">
		<title>Setting the LVQ</title>
		<para>
			This example demonstrates the use of LVQ.
		</para>
		
<programlisting>
{
#include "qpid/client/QueueOptions.h"

QueueOptions qo;
qo.setOrdering(LVQ);

session.queueDeclare(arg::queue=queue, arg::arguments=qo);

.....
string key;
qo.getLVQKey(key);

....
</programlisting>
		<para>
			For each message, set the into application headers before transfer 
<programlisting>
message.getHeaders().setString(key,"RHT");
}
</programlisting>
		</para>
	</example>

Available on the stage for review shortly.

LKB

Note You need to log in before you can comment on or make changes to this bug.