You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by tmi <mi...@web.de> on 2007/09/04 14:50:30 UTC
RE: Jms Destination lifetime question
Any JMS destinations that you create in your Java producer/consumer using
javax.jms.Session.createQueue() or createTopic() will not outlive a restart
of ActiveMQ.
Queues/topics that you want to outlive a broker restart need to be created
directly in the broker, e.g. using some sort of JMX console. For those there
are also APIs to delete these queues/topics again.
Potentially, ActiveMQ can run out of memory if too many destinations get
created.
--
View this message in context: http://www.nabble.com/Jms-Destination-lifetime-question-tf4346951s2354.html#a12477608
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Jms Destination lifetime question
Posted by ttmdev <jo...@ttmsolutions.com>.
Ooops, my-bad. The delivery mode is set to PERSISTENT. I was not using the
producer's setDeliveryMode method :o)
Joe
James.Strachan wrote:
>
> On 9/5/07, ttmdev <jo...@ttmsolutions.com> wrote:
>>
>> I am doing the following:
>>
>> 1. I start a broker with persitent="false" and no destinations defined in
>> it's xml cfg file.
>> 2. I then start a producer that looks up a queue, called Q.REQ, via the
>> Context.lookup() approach
>> 3. The producer sends 20 messages to the queue called Q.REQ w/delivery
>> mode
>> set to NON_PERSISTENT
>> 4. The producer exits
>> 5. I bounce the broker
>> 6. I then bring up my consumer, which looks up the Q.REQ via
>> Context.lookup() and it successfully read all 20 messages
>>
>> So it appears to me that destinations do outlive a restart of the broker
>> even w/out persistent messaging.
>
> Hmm, that sounds to me like thats really using persistent messaging.
> You sure the producer really is sending non-persistent (and no other
> producer is sending to that queue)?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/Jms-Destination-lifetime-question-tf4346951s2354.html#a12497131
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Jms Destination lifetime question
Posted by James Strachan <ja...@gmail.com>.
On 9/5/07, ttmdev <jo...@ttmsolutions.com> wrote:
>
> I am doing the following:
>
> 1. I start a broker with persitent="false" and no destinations defined in
> it's xml cfg file.
> 2. I then start a producer that looks up a queue, called Q.REQ, via the
> Context.lookup() approach
> 3. The producer sends 20 messages to the queue called Q.REQ w/delivery mode
> set to NON_PERSISTENT
> 4. The producer exits
> 5. I bounce the broker
> 6. I then bring up my consumer, which looks up the Q.REQ via
> Context.lookup() and it successfully read all 20 messages
>
> So it appears to me that destinations do outlive a restart of the broker
> even w/out persistent messaging.
Hmm, that sounds to me like thats really using persistent messaging.
You sure the producer really is sending non-persistent (and no other
producer is sending to that queue)?
--
James
-------
http://macstrac.blogspot.com/
Re: Jms Destination lifetime question
Posted by ttmdev <jo...@ttmsolutions.com>.
I am doing the following:
1. I start a broker with persitent="false" and no destinations defined in
it's xml cfg file.
2. I then start a producer that looks up a queue, called Q.REQ, via the
Context.lookup() approach
3. The producer sends 20 messages to the queue called Q.REQ w/delivery mode
set to NON_PERSISTENT
4. The producer exits
5. I bounce the broker
6. I then bring up my consumer, which looks up the Q.REQ via
Context.lookup() and it successfully read all 20 messages
So it appears to me that destinations do outlive a restart of the broker
even w/out persistent messaging.
Joe
James.Strachan wrote:
>
> On 9/4/07, tmi <mi...@web.de> wrote:
>>
>> Any JMS destinations that you create in your Java producer/consumer using
>> javax.jms.Session.createQueue() or createTopic() will not outlive a
>> restart
>> of ActiveMQ.
>
> They will if you use persistent messaging and you don't consume all
> the messages on a queue/topic, then on restart you recreate your
> consumer - or you specify them on startup the next time...
> http://activemq.apache.org/configure-startup-destinations.html
>
>
>> Queues/topics that you want to outlive a broker restart need to be
>> created
>> directly in the broker, e.g. using some sort of JMX console. For those
>> there
>> are also APIs to delete these queues/topics again.
>
> FWIW using a destination from Session.createQueue() /
> Session.createTopic() to send/consume messages has the same effect as
> creating the destination via JMX.
>
> i.e. the broker only allocates resources for new destinations when
> they are actually used by a producer / consumer.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/Jms-Destination-lifetime-question-tf4346951s2354.html#a12490761
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Jms Destination lifetime question
Posted by James Strachan <ja...@gmail.com>.
On 9/4/07, tmi <mi...@web.de> wrote:
>
> Any JMS destinations that you create in your Java producer/consumer using
> javax.jms.Session.createQueue() or createTopic() will not outlive a restart
> of ActiveMQ.
They will if you use persistent messaging and you don't consume all
the messages on a queue/topic, then on restart you recreate your
consumer - or you specify them on startup the next time...
http://activemq.apache.org/configure-startup-destinations.html
> Queues/topics that you want to outlive a broker restart need to be created
> directly in the broker, e.g. using some sort of JMX console. For those there
> are also APIs to delete these queues/topics again.
FWIW using a destination from Session.createQueue() /
Session.createTopic() to send/consume messages has the same effect as
creating the destination via JMX.
i.e. the broker only allocates resources for new destinations when
they are actually used by a producer / consumer.
--
James
-------
http://macstrac.blogspot.com/