I am working on a system that has large amounts of topics often connected in a network of brokers. Clients are mostly using the Stomp protocol. I am now looking at also adding potentially a lot of queues and was seeking some design advice on scalability.
For me the most important characteristic is that message latency should be low even for 1000s of subscribes, this works well today with just topics and subscribers subscribing to a topic of messages they want. I am concerned that adding a lot - 1000s - of queues would impact performance a lot due to the typical 1 thread per queue, topic and subscriber (I know these are tunable and I can use NIO). I can now redesign things so that instead of many many topics and queues I use headers and JMS selectors when subscribing and publishing, this way I can have only a hand full of queues and topics with subscribers maintaining many subscriptions on these queues/topics. It's not clear which of these two strategies will work best in the long run and so was wondering what would be the most resource intensive on the broker and the network of brokers wrt to threads, cpu, memory etc. and what would be the best practice for this kind of application keeping in mind message latency is very important. Thanks -- View this message in context: http://activemq.2283324.n4.nabble.com/Large-amounts-of-queues-and-topics-tp3471410p3471410.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
