activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GaryG <>
Subject Re: Queue question
Date Fri, 02 Feb 2007 16:03:28 GMT

Thank you for explaining the PERSISTENT setting to me. 

I'm still unclear about a few things, though.  First, what is a
DurableSubscriber then, how does that affect anything, and how does that
work with PERSISTENT/non settings?

Secondly...what I'm really trying to accomplish, is that some of the
communication I have is being broadcast on Topics, in which case I don't
care about persistence, and it would make sense to turn that off.  

However, other communication I have going on between controller module and
worker modules, and since I want my workers to come up/down dynamically,
with unique communication channels, I made them into Queues.  The problem
is, however, if a worker (Q consumer) goes down, and he was talking via Q
named "Q1", for example, when he comes back lets say 10 minutes later, I
don't necessarily want him to receive all the messages he missed while being
down.  Those messages might've already been detected by the controller as
not having been received, and parcelled out to some other worker.  So in
this case, whatever action the messages were directing the worker to take,
would be done twice.

Can this be alleviated by turning off AUTO_ACKNOWLEDGE and setting to
CLIENT_ACK ?  How about the TTL setting when publishing the messages?

Ideally...what should happen is that when a message is sent on the Q, if
no-one's listening, it should expire after a short time, and it's okay that
it's lost.  Just like how the Topics work.  

Maybe this means I should be using Topics in all cases?

Thanks for any help!


YoungSoul wrote:
> As far as I know - and someone please correct me if I am wrong...
> The NON_PERSISTENT has to do with whether or not the jms service provider
> ( activemq in this case ) will persist the message in case ACTIVEMQ dies. 
> If you try your scenario below but add step 2.5 of stop activemq, since
> you send deliver NON_PERSISTENT messages, activemq only holds them in
> memory and will be lost.  Bring up your consumer in step 3 and it should
> receive nothing.
> So your scenario below is working as expected with queues.
> DurableSubscription is only for Topic subscribers.
> When you say you want 'delivery assurance' it depends on your
> requirements.  If you need that message to go to a queue subscriber even
> in the face of jms provider failure then you will have to publish with
> PERSISTENT turned on.  If you mean you need to deliver them whether the
> consumer is there or not, and you dont care about provider failures, then
> you can send NON_PERSISTENT and just bring consumers up and down at will.
> GaryG wrote:
>> I'm doing some simple communication between two peers via a Queue, and
>> I'm noticing odd persistence behavior.
>> Even though the producer is set with DeliveryMode.NON_PERSISTENT, what I
>> see happen is this:
>> 1) Bring up AMQ broker
>> 2) Bring up Producer and send 5 test messages.  At this point the
>> consumer of the messages for this Q is not even running.
>> 3) Bing up Consumer and it receive the 5 messages.
>> I've tried setting TTL on the Producer to something really short, but
>> that didn't help.  I'm using Session.AUTO_ACKNOWLEDGE.
>> This seems wrong to me, as I would only expect the messages to be
>> delivered to the consumer of the Q if the consumer was A) actually
>> running, or B) there was persistence turned on.
>> If I use a Topic instead, the above scenario works as expected, and I
>> only get the missed messages if I turn on persistence.
>> What am I missing?
>> Perhaps I'm not grasping what persistence is and how it should work?  I
>> understand the messages persisted to a DB for backup, how is that
>> different from journaling?  If I want delivery assurance, even if a
>> consumer is down, do I have to turn on DeliveryMode.PERSISTENT on the
>> producer, AND use a DurableSubscriber on the consumer end?
>> I appreciate any help!
>> -GaryG

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message