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 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 <seij...@gmail.com> 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 <rajdav...@gmail.com> wrote:
>
>> 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-jms.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).
>> However, for your case you probably need to enable GC on destinations - see
>> http://activemq.apache.org/delete-inactive-destinations.html
>>
>> On 10 Oct 2013, at 05:11, javaG <zenma...@gmail.com> 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:
>>> http://activemq.2283324.n4.nabble.com/Too-many-advisories-topics-created-in-ActiveMQ-tp4672501.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
