2 Replies Latest reply on Dec 14, 2007 6:45 PM by Hiram Chirino

    Scaling number of connections in activemq

    Nicholas Hanssens Newbie

      Hi all.


      I've been hunting around the net trying to find an answer to this question but haven't found anything definitive.



      I am trying to deploy activemq in an environment with a very large number of very low-traffic connections. To be cost-effective, I need (at a minimum) 1k connections per server, and would prefer to be up around 10k.



      I ran some tests on this and, unsurprisingly, it is allocating one thread per connection which really cannot scale effectively. The "correct" solution in this case would be to use NIO connections instead of the older-style threaded model. I've found a number of vague reverences to support for NIO in the activemq docs, but no actual reference of how to go about doing this.


      Does such support actually exist? Can it be configured?


      Alternatively, I could just write a quick relay that multiplexes many NIO connections into one 'standard' connection, but I'd much rather use a native solution.




      Nicholas Hanssens

      Platform Architect


        • 1. Re: Scaling number of connections in activemq
          Robert Davies Newbie

          Hi Nicholas,


          The FUSE Message Broker does support a non-blocking i/o through the use of nio - which is used instead on of the tcp:// protocol for a broker connection.

          e.g. - whilst your clients may use tcp://somehost:61616 as the uri, configure the broker to listen on nio://localhost:61616.


          Modern operating systems can handle a very large number of threads however, and we have scaled to 1000 clients and above using blocking i/o.





          • 2. Re: Scaling number of connections in activemq
            Hiram Chirino Newbie

            Hi Nicholas,


            One of the simplest ways to increase the number of connections that the broker can handle is to figure out the optimal thread stack size for the broker on your JVM/OS combination.  By default on Windows, stack sizes are very large.  On most JVMs you configure this setting with the -Xss JVM option.


            I would start with trying a -Xss512k stack size option on the broker.  Load test you system and the broker did not report any stack problems try to go with an even lower setting.  This will lower the amount of memory each created thread allocates.