activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <>
Subject Re: Too many advisories topics created in ActiveMQ
Date Thu, 10 Oct 2013 05:30:31 GMT
Rob - that is actually what I was thinking :)
What I normally do is 

1 - Use camel - Unless there is a specific use-case for batching / TX most modern systems
tend to be record oriented.
   1.5 - If you need by record and ordering you are doing something wrong :)
2 - Separate connectionFactories and rely on the beauty of NIO in AMQ.
    2.1 - Don't use PooledConnectionFactory for both listening and producing, it'll just give
you migraines.
3 - Look at the specific use-case, is this volume or size or both - That'll lead to concurrent
consuming and prefetch.
4 - Most likely since this is 1.4 J2EE compatible, disable compression, wire changes, whatnot
5 - Make your request reply happen in two different Executors, with two separate runnables,
respect the Correlation ID
    5.1 - You can use one queue. 
    5.2 - If you use temp destinations, use the correlation and keep the queue (You get cleanup
for free).

Look at volume produced vs. consumed. - What is a Request reply actually in terms of work?
That last one is hard, that is the key to scaling systems as you left the world of 

Person findPerson(Number id);

(You can infer british rock here.)

Just some ideas of the top of my head...

On Oct 9, 2013, at 11:14 PM, Johan Edstrom <> wrote:

> As Rob pointed out, there are several solutions to this, the simplest one 
> being as in the old joke, Dr, it hurts when I do this. - Don't do it?
> You could achieve the same thing with one queue and selectors - *which could run CPU
> You could use a temp queue per processing unit and handle a lot of messages (This is
nice for pub/sub)
> You could use one queue and a bit of instanceof code (It looks a bit crufty but it is
very functional)
> On Oct 9, 2013, at 11:05 PM, Robert Davies <> wrote:
>> What you have described is a bit of an anti-pattern - there's some guidelines here
in the faq:
>> Its an anti-pattern because there is a lot of broker side over head with creating
temporary destinations and consumers (as you are seeing). 
>> However, for your case you probably need to enable GC on destinations - see
>> On 10 Oct 2013, at 05:11, javaG <> wrote:
>>> In my application, I use request-reply by creating temp queue and creating a
>>> new replyConsumer for each message to use replyConsumer.poll() method to get
>>> reply back. After getting reply I close the replyConsumer. Messaging works
>>> fine but each time a message is sent a topic
>>> ActiveMQ.Advisory.Consumer.Queue.ID:xxxxxxxxxxxxxx is created and remains
>>> there. So if millions of messages are sent millions of rows will be created
>>> in the ActiveMQ web console for topics.  I tried to disable advisories
>>> message to solve this problem but then request-reply does not work anymore
>>> as it throws exceptions like Cannot publish to a deleted destination. So I
>>> am stuck. Any one has a solution?
>>> Thanks
>>> --
>>> View this message in context:
>>> Sent from the ActiveMQ - User mailing list archive at

View raw message