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 <[EMAIL PROTECTED]> 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/
