You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by GaryG <gg...@us.ibm.com> on 2007/02/01 20:48:56 UTC
Queue question
I'm doing some simple communication between two peers via a Queue, and I'm
noticing odd persistence behavior.
Even though both 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.
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: http://www.nabble.com/Queue-question-tf3157001.html#a8755070
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by James Strachan <ja...@gmail.com>.
On 2/5/07, GaryG <gg...@us.ibm.com> wrote:
> GaryG wrote:
> >
> >
> > On 2/5/07, Givental, Gary wrote:
> >> Ah yes, I should have clarified that :)
> >>
> >> The nature of the applications makes that impossible. We need to
> >> ensure that A) all the tasks are processed in sequential order, B)
> >> each work task is tied to a specific business entity. If 2 tasks need
> >> to be done for the same business entity, they *must* be processed in
> >> time-sequential order, and be processed by the Worker.
> >>
> >> These two requirements do not allow us to use a Queue for all the
> >> worker tasks, since that would mean they they might be processed out
> >> of order, and even worse, 2 tasks for the same business entity might
> >> be processed out of time-sequence.
> >
> >
> >
>
>
>
> > Aha. Looks like you need to use Message Groups. Using the business entity
> > as the JMSXGroupID value - then you get load balancing across your
> > business entities and workers - yet each business entity's messages are
> > processed in time-sequential order
> >
> > http://activemq.apache.org/message-groups.html
> >
> > If you need to preserve the order of all messages across all business
> > entities (i.e. process all messages essentially single threaded), then you
> > could use Exclusive Consumers
> >
> > http://activemq.apache.org/exclusive-consumer.html
> >
> > in either case, the broker does the hard work of tracking workers and load
> > balancing etc
> > --
> > James
> >
>
>
> In response to this, James, does it effect performance negatively to have
> thousands of message groups? on the order of 10,000?
No, not really. We kinda guessed folks would use lots of message
groups, so we end up using the hash function of the JMSXGroupID
string, then assign hash bucket ranges to consumers. So you can use as
many message groups as you like. (If you're interested, this code is
in the MessageGroupHashBucket). The default number of buckets is 1024
which should be fine for most uses but you can make that higher if you
require - the only real cost of an increased number of buckets is more
RAM for the data structure.
> Also, it sounds like Message Groups are Topics (publish/subscribe) is that
> correct?
No, they are queues (each message is processed by exactly one
consumer). Message Groups kinda implement sticky load balancing like
websites - only rather than a jsessionid or cookie, its using
JMSXGroupId as the 'session id'. Another way to look at Message Groups
is they are a way of splitting a queue into many separate Exclusive
Queues which are then spread across the consumers.
> What about the use case (building on the Stock Symbols example on the
> activemq site) where perhaps all the Stock Symbols (MSFT, IBM, etc) are
> unique Message Groups, but we also want to group all the stock that are for
> Internet Companies, and a group for all the automotive industry companies,
> etc...is there sub-grouping in other words?
No, I'm afraid not. There is just one level of grouping, the value of
the JMSXGroupID you choose. So if you want to process all automotive
companies in order by one single thread / consumer - then choose, say,
"automotive" as the JMSXGroupID.
You could do futher traffic shaping by using multiple queues. So you
could use a queue for "automotive" then use message groups within it
if needed.
> I'm also concerned about memory requirements and performance of the broker
> itself
It doesn't affect memory & performance much, as the broker already
load balances messages on a queue across the consumers; its really
just an extra check to see which consumer owns a group using an
efficient hash bucket data structure.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Queue question
Posted by GaryG <gg...@us.ibm.com>.
[backfilling some messages]
GaryG wrote:
>
>
> On 2/5/07, Givental, Gary wrote:
>> Ah yes, I should have clarified that :)
>>
>> The nature of the applications makes that impossible. We need to
>> ensure that A) all the tasks are processed in sequential order, B)
>> each work task is tied to a specific business entity. If 2 tasks need
>> to be done for the same business entity, they *must* be processed in
>> time-sequential order, and be processed by the Worker.
>>
>> These two requirements do not allow us to use a Queue for all the
>> worker tasks, since that would mean they they might be processed out
>> of order, and even worse, 2 tasks for the same business entity might
>> be processed out of time-sequence.
>
>
>
> Aha. Looks like you need to use Message Groups. Using the business entity
> as the JMSXGroupID value - then you get load balancing across your
> business entities and workers - yet each business entity's messages are
> processed in time-sequential order
>
> http://activemq.apache.org/message-groups.html
>
> If you need to preserve the order of all messages across all business
> entities (i.e. process all messages essentially single threaded), then you
> could use Exclusive Consumers
>
> http://activemq.apache.org/exclusive-consumer.html
>
> in either case, the broker does the hard work of tracking workers and load
> balancing etc
> --
> James
>
In response to this, James, does it effect performance negatively to have
thousands of message groups? on the order of 10,000?
Also, it sounds like Message Groups are Topics (publish/subscribe) is that
correct?
What about the use case (building on the Stock Symbols example on the
activemq site) where perhaps all the Stock Symbols (MSFT, IBM, etc) are
unique Message Groups, but we also want to group all the stock that are for
Internet Companies, and a group for all the automotive industry companies,
etc...is there sub-grouping in other words?
I'm also concerned about memory requirements and performance of the broker
itself
--
View this message in context: http://www.nabble.com/Queue-question-tf3157001.html#a8814454
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by GaryG <gg...@us.ibm.com>.
[backfilling some messages]
> James,
>
> I appreciate your help on this.
>
> To clarify, here's the gist of what I'm trying to accomplish:
>
> Essentially it is a worker farm that is controlled via a single master
> controller. There are some Topics on which status information is
> published by the workers, and the controller can issue control
> commands.
>
> However the actual work tasks I currently have parceled out to the
> workers on Queues. When a worker is brought online, it posts on the
> Status Topic that it's alive, and its name is "Worker1". At that
> point the worker creates a Queue listener for "Worker1_Tasks", and the
> controller creates a "Worker1_Tasks" message producer.
Though it sounds like you're missing one of the main benefits of Queues -
which is namely to act as a load balancer. A queue can have many consumers
competing for messages - such that messages are load balanced across the
available workers so that each message is processed exactly once - so its
ideal for the parallel worker pattern.
So why not have a single queue "Workers" and let all the individual workers
compete on that queue, load balancing requests and dealing with failover of
workers?
--
James
-------
--
View this message in context: http://www.nabble.com/Queue-question-tf3157001.html#a8814319
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by James Strachan <ja...@gmail.com>.
Its maybe best if you step back a bit and clearly describe the exact
semantics you want for your message exchanges as it sounds a little
like a few concepts are being muddled together. Lets start with the
absolute basics of how queues and topics differ...
http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html
once you have the core sematics (one message to only one consumer
versus one message to all available consumers at the point that the
message is sent), we can take it from there and refine to do what you
need - such as using a timeout on the message (so messages don't stay
around forever), temporary destinations or other MOM conventions.
On 2/2/07, GaryG <gg...@us.ibm.com> wrote:
>
> 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!
>
> -GaryG
>
>
> 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: http://www.nabble.com/Queue-question-tf3157001.html#a8769592
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Queue question
Posted by GaryG <gg...@us.ibm.com>.
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!
-GaryG
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: http://www.nabble.com/Queue-question-tf3157001.html#a8769592
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by YoungSoul <yo...@inbox.com>.
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: http://www.nabble.com/Queue-question-tf3157001.html#a8767619
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by GaryG <gg...@us.ibm.com>.
Thanks for the clarification.
While poking around with JConsole connecting to the broker via JMX I found
the option to purge Queues. And after tweaking with the code a bit, came up
with the following piece of code that actually *does* purge a queue.
Has anyone used this approach before and are there any reason not to do this
on Q's? (ie. use Topics instead). It just feels odd to be using topics
when the communication is known to be P2P.
------------------
JMXServiceURL u = new
JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi");
JMXConnector c = JMXConnectorFactory.connect(u);
c.connect();
ObjectName objName = new
ObjectName("org.apache.activemq:BrokerName=localhost,Type=Queue,Destination="
+ qName);
c.getMBeanServerConnection().invoke(objName, "purge", null, null);
System.out.println("invoked purge command on Q = " + qName);
-----------------
James.Strachan wrote:
>
> Persistence v non persistence only applies to what happens to messages
> if you reboot the broker; otherwise the semantics are pretty similar.
>
> If you don't want a message to be sent to consumers which are not
> there, don't use a queue, use a topic.
>
>
> On 2/1/07, GaryG <gg...@us.ibm.com> wrote:
>>
>> I'm doing some simple communication between two peers via a Queue, and
>> I'm
>> noticing odd persistence behavior.
>>
>> Even though both 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.
>>
>> 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:
>> http://www.nabble.com/Queue-question-tf3157001.html#a8755070
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
--
View this message in context: http://www.nabble.com/Queue-question-tf3157001.html#a8775822
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Queue question
Posted by James Strachan <ja...@gmail.com>.
Persistence v non persistence only applies to what happens to messages
if you reboot the broker; otherwise the semantics are pretty similar.
If you don't want a message to be sent to consumers which are not
there, don't use a queue, use a topic.
On 2/1/07, GaryG <gg...@us.ibm.com> wrote:
>
> I'm doing some simple communication between two peers via a Queue, and I'm
> noticing odd persistence behavior.
>
> Even though both 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.
>
> 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: http://www.nabble.com/Queue-question-tf3157001.html#a8755070
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/
RE: Queue question
Posted by "Suchitha Koneru (sukoneru)" <su...@cisco.com>.
Please read about queueing and durable subscriptions from the following
link
http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html
-----Original Message-----
From: GaryG [mailto:ggiventa@us.ibm.com]
Sent: Thursday, February 01, 2007 11:49 AM
To: activemq-users@geronimo.apache.org
Subject: Queue question
I'm doing some simple communication between two peers via a Queue, and
I'm noticing odd persistence behavior.
Even though both 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.
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:
http://www.nabble.com/Queue-question-tf3157001.html#a8755070
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Queue question
Posted by "Suchitha Koneru (sukoneru)" <su...@cisco.com>.
When you use a queue connection , irrespective of other settings,
message delivery is guaranteed.
When you use a topic connection , message delivery is guaranteed only
when the delivery mode is persistent and the subscriber is durable.
Suchitha.
-----Original Message-----
From: GaryG [mailto:ggiventa@us.ibm.com]
Sent: Thursday, February 01, 2007 11:49 AM
To: activemq-users@geronimo.apache.org
Subject: Queue question
I'm doing some simple communication between two peers via a Queue, and
I'm noticing odd persistence behavior.
Even though both 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.
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:
http://www.nabble.com/Queue-question-tf3157001.html#a8755070
Sent from the ActiveMQ - User mailing list archive at Nabble.com.