Hi, We have ~100 remote brokers establishing a duplex SSL network connector to a single central "hub" broker. We use this for store and forward of messages in both directions. All JMS consumers and producers execute in-process against their local broker and JMS resources are pooled with PooledConnectionFactory.
We're not having any problems but I am surprised by the sheer volume (~ 350 or so) of the "VMTransport: vm://<ourBroker>" threads that seem to be alive in the hub's process at any given time. The figure fluctuates as the # of connected remote brokers changes. In digging through the source code, this appears correlated to the fact there are ~180 VMTransport instances ,each of which has created an independent ThreadpoolExecutor by way of TaskRunnerFactory. Each of these executor's rarely has more then one thread "alive" at a time (in TIME_WAITING) but there are many executors so there are many threads. Is there any provision to share a thread pool between the VMTransports ? I could be missing something but if each VMTransport is creating its own thread pool, doesn't that mean more threads could be created then necessary ? When VMTransport "A" needs work done, there could be an idle thread available in VMTransport "B"'s pool but it can't be used to do that work. Instead, VMTransport "A"'s ThreadPoolExecutor (might) create a new thread. Some thread thrashing can be reduced by tuning the individual pool's (core size, keep alive..etc) parameters but if each VMTransport is utilizing a separate pool, isn't the pooling less effective "globally" ? -- View this message in context: http://activemq.2283324.n4.nabble.com/VMTransport-threading-tp4719974.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
