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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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#a12552462
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
