You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Juergen Mayrbaeurl <ju...@hvb.sozvers.at> on 2007/09/06 13:29:52 UTC
Strict order of messages with redelivery
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?
Kind regards
Juergen
PS: We're using ActiveMQ 4.1.0
--
View this message in context: http://www.nabble.com/Strict-order-of-messages-with-redelivery-tf4391491s2354.html#a12520552
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Strict order of messages with redelivery
Posted by Juergen Mayrbaeurl <ju...@hvb.sozvers.at>.
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 <ju...@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 <ju...@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.
Re: Strict order of messages with redelivery
Posted by Juergen Mayrbaeurl <ju...@hvb.sozvers.at>.
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 <ju...@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 <ju...@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#a12552462
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Strict order of messages with redelivery
Posted by James Strachan <ja...@gmail.com>.
Any chance you could try 4.1.1?
On 9/7/07, Juergen Mayrbaeurl <ju...@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 <ju...@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/
Re: Strict order of messages with redelivery
Posted by Juergen Mayrbaeurl <ju...@hvb.sozvers.at>.
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 <ju...@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.
Re: Strict order of messages with redelivery
Posted by Juergen Mayrbaeurl <ju...@hvb.sozvers.at>.
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 <ju...@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#a12538047
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Strict order of messages with redelivery
Posted by James Strachan <ja...@gmail.com>.
On 9/6/07, Juergen Mayrbaeurl <ju...@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/