activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Mayrbaeurl <juergen.mayrbae...@hvb.sozvers.at>
Subject Re: Strict order of messages with redelivery
Date Fri, 07 Sep 2007 14:10:21 GMT

Hi!

Sorry! The solution isn't that easy, because my fix will only work, if all
pending messages were dispatched. Even worse, it doesn't explain/solve my
orginal problem. I think some more investigations are necessary.

Kind regards
Juergen


Juergen Mayrbaeurl wrote:
> 
> Hi James!
> 
> I did some debugging and found the problem.
> 
> On deactivating an durable topic subscription (method deactivate() in
> org.apache.activemq.broker.region.DurableTopicSubscription and having
> "keepDurableSubsActive " set to true, the dispatched messages get iterated
> from the first to the last but are always put in the pending list at the
> first entry. Source:
> 
>         for (Iterator iter = dispatched.iterator(); iter.hasNext();) {
> 
>             // Mark the dispatched messages as redelivered for next time.
>             MessageReference node = (MessageReference) iter.next();
>             Integer count = (Integer)
> redeliveredMessages.get(node.getMessageId());
>             if( count !=null ) {
>                 redeliveredMessages.put(node.getMessageId(), new
> Integer(count.intValue()+1));
>             } else {
>                 redeliveredMessages.put(node.getMessageId(), new
> Integer(1));
>             }
>             if( keepDurableSubsActive ) {
>             	synchronized(pending) {
>             		pending.addMessageFirst(node);
>             	}
>             } else {
>                 node.decrementReferenceCount();
>             }
>             iter.remove();
>         }
> 
> I think this can be fixed quite easy by replacing
> pending.addMessageFirst(node) with pending.addMessageLast(node).
> 
> BTW: What happens when the flag keepDurableSubsActive is set to false? And
> how (or where) can it be set. Documentation says it defaults to "false".
> It seems to be true in our message broker configuration (but not set
> explizitly).
> 
> Kind regards
> Juergen
> 
> 
> James.Strachan wrote:
>> 
>> Any chance you could try 4.1.1?
>> 
>> On 9/7/07, Juergen Mayrbaeurl <juergen.mayrbaeurl@hvb.sozvers.at> wrote:
>>>
>>> I did the same test with transacted sessions and the result is the same.
>>> --> The order gets reversed after each attempt.
>>>
>>> Anyone seen this behaviour before? James told me that it should work as
>>> expected! What's about version 4.1.1? Fixed? Or: It's not a bug, it's a
>>> feature.
>>>
>>> Kind regards
>>> Juergen
>>>
>>>
>>> Juergen Mayrbaeurl wrote:
>>> >
>>> > Unfortunately the ordering doesn't work with client acknowledge in
>>> 4.1.0
>>> > as the following example shows
>>> >
>>> > 1) 10 messages for topic produced
>>> > 2) First attempt to receive the messages with a durable topic
>>> subscriber
>>> > (acknowledment mode set to client acknowlede but not called for any of
>>> the
>>> > messages)
>>> >
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:1
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:2
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:3
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:4
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:5
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:6
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:7
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:8
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:9
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:10
>>> >
>>> > 3) Second attempt
>>> >
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:10
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:9
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:8
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:7
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:6
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:5
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:4
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:3
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:2
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:1
>>> >
>>> > 4) Third attempt:
>>> >
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:1
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:2
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:3
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:4
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:5
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:6
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:7
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:8
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:9
>>> > Message ID: ID:hvb0396-1306-1189153233546-1:0:1:1:10
>>> >
>>> > As you can see the order gets reversed after each attempt. I'll do
>>> some
>>> > further testing with tranacted sessions.
>>> >
>>> > Kind regards
>>> > Juergen
>>> >
>>> >
>>> > James.Strachan wrote:
>>> >>
>>> >> On 9/6/07, Juergen Mayrbaeurl <juergen.mayrbaeurl@hvb.sozvers.at>
>>> wrote:
>>> >>>
>>> >>> Hi!
>>> >>>
>>> >>> Our application has to make sure that all consumers with durable
>>> topic
>>> >>> subscriptions get messages in strict order even when a message has
>>> to be
>>> >>> delivered.
>>> >>> E.g.
>>> >>> Publisher puts message 1 to 10 on topic. Consumer opens a session,
>>> gets
>>> >>> message 1, makes a client acknowledment, gets message 2, makes a
>>> client
>>> >>> acknowledment, and so on. On message 3 a runtime exception occurs
>>> and no
>>> >>> client acknowledment is done, but the session and the connection
are
>>> >>> closed.
>>> >>> The next time the consumer opens a session message 4 gets delivered
>>> >>> before
>>> >>> message 3.
>>> >>>
>>> >>> What do we have to do to get message 3 (and not 4) as the first
>>> message?
>>> >>> Do
>>> >>> we have to use a special redelivery policy?
>>> >>
>>> >> It should just work; though FWIW I'd recommend you switch from using
>>> >> acknowledge to using JMS transactions. They are typically faster as
>>> >> well as allowing you to do a rollback (rather than having to close
>>> the
>>> >> session & connection on failure)
>>> >> http://activemq.apache.org/should-i-use-transactions.html
>>> >>
>>> >>
>>> >>> PS: We're using ActiveMQ 4.1.0
>>> >>
>>> >> I'd also recommend you upgrade to 4.1.1
>>> >> --
>>> >> James
>>> >> -------
>>> >> http://macstrac.blogspot.com/
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Strict-order-of-messages-with-redelivery-tf4391491s2354.html#a12542296
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>>
>> 
>> 
>> -- 
>> James
>> -------
>> http://macstrac.blogspot.com/
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Strict-order-of-messages-with-redelivery-tf4391491s2354.html#a12556038
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message