Mix static and dynamic queues reasonable?

[AgathoSAreS <ag...@gmail.com>]

We implement ActiveMQ on a JBOSS Server. I have no more information about the
system environment.
On client side, we will have around 2000 consumers / producers.

The discussion now is about two options:
1. have dynamic inbound and outbound queue for every user. (4000 queues)
2. Go to 1 to 5 static queues for Inbound and 1 to 5 dynamic queues for
Outbound as the image below shows.

<http://activemq.2283324.n4.nabble.com/file/n4708437/activmq2.png> 

(I can't see what they want to achieve with 1 to 5 dynamic queues, makes no
sense to me)
What are your thoughts on this solution?



--
View this message in context: http://activemq.2283324.n4.nabble.com/Mix-static-and-dynamic-queues-reasonable-tp4708437.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Mix static and dynamic queues reasonable?

[artnaseef <ar...@artnaseef.com>]

That's too little information to judge really.

4,000 queues is a lot, but ActiveMQ can be tuned to handle that many well. 
As for "static" vs "dynamic", I'm not sure what that means.  If it means
that the queue names may change for "dynamic" and not change for "static",
then there are many considerations there.  Certainly, I would say that using
fixed-named queues for the large 4,000 count is a good thing.

Using varying queue names over time is alright as long as it doesn't happen
too rapidly.  Queue creation and cleanup is not light-weight.  For example,
an application creating queues at a rate of, say, 100 per minute would
really worry me - in terms of the overhead it creates.  Such a pattern would
also make maintaining the broker tough (it would be hard to even get a clear
view of the list of queues in existence at any point in time).

Let me stop making assumptions here.

Hope this helps.




--
View this message in context: http://activemq.2283324.n4.nabble.com/Mix-static-and-dynamic-queues-reasonable-tp4708437p4708478.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.