What about using selective consumers? That way one queue can act like multiple queues.
Joe Get a free ActiveMQ user guide @ http://www.ttmsolutions.com lawrencek wrote: > > Hi, > > I'm designing a system that will have a few central services and upward of > 6000 processes on thousands of machines on a LAN. They all communicate > using ActiveMQ, with the central services having well-known queue names > and the distributed components having randomly-generated queue names. I > recently profiled the broker and found that every queue results in four > threads (one for the queue, one for checkpoint (?), and two for each of > two related topics (consumer and producer)). Additionally, every > connection to the broker results in two threads (dispatcher and > transport). That means that each of the 6000 distributed components will > result in six threads, or 36,000 threads total in the broker. I don't know > whether using a network of brokers will allow me to reduce this to a > reasonable number per process. I also have to worry about the 6000 TCP > connections to the broker, which could also presumably be distributed > across a network of brokers. > > More generally, though, I'm concerned that ActiveMQ, and really JMS, was > never intended to support this many clients. Perhaps I should use JMS only > for communication amongst the central services, and all communication > to/from the distributed services should use a simpler RPC scheme. > > Does anyone know if ActiveMQ can handle this many clients? What's the most > number of clients anyone has seen on ActiveMQ or JMS? > > Thanks, > > Lawrence > > -- View this message in context: http://www.nabble.com/6000-ActiveMQ-clients-tp19983973p19985274.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
