Bug 479423

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.

Please replace the current test in chapter 3 on Last Value Queue with the above expanded version.

thanks

	<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