qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Delivery order of LVQ data?
Date Mon, 23 Jul 2012 14:33:39 GMT
On 07/23/2012 01:58 PM, Toralf Lund wrote:
> On 23/07/12 10:42, Gordon Sim wrote:
>> On 07/23/2012 08:27 AM, Toralf Lund wrote:
>>> Hi.
>>> In my C++ messaging client, I'm reading data from a last-value queue via
>>> a loop that's essentially as follows:
>>> while(1) {
>>>     try
>>>        session.sync();
>>>        qpid::messaging::Receiver receiver=session.nextReceiver(timeout);
>>>        message=receiver.fetch(qpid::messaging::Duration::IMMEDIATE);
>>>        session.acknowledge();
>>>        messageType=message.getProperties()["message_type"].asString();
>>> < handle the data... >
>>>     } catch(const qpid::messaging::NoMessageAvailable &error) {
>>>     }
>>> }
>>> At the moment, the session has just one receiver, associated with a
>>> "common" LVQ for all the data. "message_type" is registered as last
>>> value queue key via "qpid.last_value_queue_key: message_type" in the X
>>> declare arguments. The receiver is also set up with "mode: browse".
>>> In what order can I expect to get data from these calls? Note that
>>> "replacements" in the terms of the LVQ behaviour may well appear on the
>>> way.
>> The messages should be delivered in FIFO order from the LVQ.
> OK.
>>> The reason why I'm asking is that although the above works in a way, in
>>> some cases I never seem to receive certain "message_type"s that are
>>> supposed to be on the queue. One possible explanation is perhaps that
>>> "replacement" messages from data that I've read in the past keeps
>>> appearing, and will get priority so that I never get to some of the
>>> unread types, if you know what I mean. But I may be seeing something
>>> else entirely...
>> When a new message arrives with a key matching an existing message,
>> the older message will be removed, and the new one added in a new
>> position at the end of the queue. Replacement messages therefore move
>> the key back in the delivery order.
> And this is done regardless of whether the original messages where
> actually delivered to the application(s)? I suppose it must be, since
> it's not for the (shared browse-only) queue to know who exactly is
> supposed to read the data...
> I think this could be my problem, which would kind of make it the
> opposite of what I suggested. The thing is, some of the messages that
> appear to be missing are actually transferred at a higher rate that most
> others, which at least makes it more likely that I won't be able to read
> one particular "instance" before it's replaced... If it also turns out
> that I can't even get through all the "lower rate" messages before new
> versions appear, surely I may have a scenario where the "fast" data
> continues to be pushed back in the queue?

Yes, that could be the case...

> I really don't see any reasons why I shouldn't be able to handle *all*
> messages, though, so perhaps I need to check my receiver setup again...
>> They do not let that key leapfrog over other keys, so cannot delay
>> delivery of other existing values.
>> I suppose in theory it would be possible for a particular interleaving
>> to continually delay delivery of a particular key, such that it was
>> never delivered. It seems unlikely, and I haven't succeeded in
>> reproducing it, but I couldn't rule it out completely.
>> What capacity are you using on the receiver?
> At the moment, just 1 - to make sure nextReceiver() will actually return
> something... Perhaps this makes the message reception very inefficient?

It can certainly slow down the browser quite a lot.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message