activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Davies <>
Subject Re: Too many advisories topics created in ActiveMQ
Date Thu, 10 Oct 2013 05:46:53 GMT
all good advice!
On 10 Oct 2013, at 06:30, Johan Edstrom <> wrote:

> 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 else.
> 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
> 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 up*
>> 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
>>>> new replyConsumer for each message to use replyConsumer.poll() method to
>>>> 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
>>>> 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