Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of seijoed@gmail.com designates
 209.85.223.172 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Too many advisories topics created in ActiveMQ
From: Johan Edstrom <seijoed@gmail.com>
In-Reply-To: <4CB65FB8-1361-48AB-9782-E11586150C5F@gmail.com>
Date: Wed, 9 Oct 2013 23:30:31 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <844BBC72-56A9-4C33-B218-2473092A41C3@gmail.com>
References: <1381378292338-4672501.post@n4.nabble.com>
 <6FF1E7CE-3F09-4A6A-8E86-115973B1CDE5@gmail.com>
 <4CB65FB8-1361-48AB-9782-E11586150C5F@gmail.com>
To: users@activemq.apache.org

Rob - that is actually what I was thinking :)
What I normally do is=20

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.=20
    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=20

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 <seijoed@gmail.com> wrote:

> As Rob pointed out, there are several solutions to this, the simplest =
one=20
> being as in the old joke, Dr, it hurts when I do this. - Don't do it?
>=20
> 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)
>=20
>=20
> On Oct 9, 2013, at 11:05 PM, Robert Davies <rajdavies@gmail.com> =
wrote:
>=20
>> What you have described is a bit of an anti-pattern - there's some =
guidelines here in the faq: =
http://activemq.apache.org/how-should-i-implement-request-response-with-jm=
s.html
>> Its an anti-pattern because there is a lot of broker side over head =
with creating temporary destinations and consumers (as you are seeing).=20=

>> However, for your case you probably need to enable GC on destinations =
- see http://activemq.apache.org/delete-inactive-destinations.html
>>=20
>> On 10 Oct 2013, at 05:11, javaG <zenmatix@gmail.com> wrote:
>>=20
>>>=20
>>> 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?
>>>=20
>>> Thanks
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> View this message in context: =
http://activemq.2283324.n4.nabble.com/Too-many-advisories-topics-created-i=
n-ActiveMQ-tp4672501.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>=20
>=20