activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kieran1 <KMur...@herzumsoftware.com>
Subject Re: Bug in failover transport
Date Tue, 28 Nov 2006 21:57:38 GMT

In my testing of this scenario, it appears that at step 9 -- 11 messages are
sent to the consumer -- there is a problem: the first of those 11 messages
is the new message sent in step 8.  

That new message should not be consumed until all of the old messages have
been consumed, right?

I have been testing this with the same problem on both 4.0.1 and 4.0.2.

Kieran


Danielius Jurna wrote:
> 
> Thanks for your explanations. It gave a little light for this problem.
> 
> After some more investigation, it seems, that there is only minor issue
> regarding failover.
> If there's more messages in the queue, than queue prefetch size, messages
> that are not yet delivered to the client before failover are still kept in
> the queue. They are only delivered when new message is sent to the queue.
> This is a little complicated. This is the scenario:
> 1. Queue prefetch size is set to 90.
> 2. 100 messages are sent to queue.
> 3. 90 messages are prefetched to the client.
> 4. Connection is recovered.
> 5. Lots of invalid ack warrnings (this is correct bahavior)
> 6. Client sends valid ack messages.
> 7. There are still 10 messages in the queue which somehow got stuck on the
> broker. Client doesn't receive anything. (incorrect behaviour)
> 8. One message is sent to the qeue.
> 9. 11 Messages are delivered to client (correct behaviour).
> 
> So the only problem, is that some messages are waiting till somebody
> publishes something to the queue. So for me it's only a minor issue,
> because our queues are quite busy :-)
> 
> 
> Hiram Chirino wrote:
>> 
>> This is tricky bug, but it might be normal.  It gets a little
>> complicated, but let me try to explain what I think is happening:
>> 
>>  (1) Say broker sends messages A,B,C,D to client
>>   (2) Client acks message A and B
>>   (3) Connection failure occurs while ack B is being delivered to broker
>>  (4) Connection is 'recovered'
>>        (4.1) If the clients previous connection is still connected to
>> the broker (client reconnect quicker than broker can detect client
>> failure), then the broker forcibly disconnects the previous
>> connection.  This cause all previous subscriptions to be destroyed.
>>        (4.2) Client replays all connection state including open
>> subscriptions to the broker
>>        (4.3) Client resends the ack that was in flight when the
>> failure occurred.
>>        (4.4) Since broker has not sent the new subscription any
>> messages yet, it does not match anything sent to the client and we get
>> the "Invalid acknowledgment" message.
>>        (4.5) Broker re-sends message B,C,D to client
>> 
>> Now in the scenario above the worst case is that B is delivered 2
>> times.  But since 4.5 and 4.4 occur concurrently there could be some
>> subtle bugs in the code that need a closer look.
>> 
>> Anyways.. I hope this help shed some light into the issue.
>> 
>> 
>> -- 
>> Regards,
>> Hiram
>> 
>> Blog: http://hiramchirino.com
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Bug-in-failover-transport-tf2587218.html#a7588764
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message