activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsargant <rsarg...@tvrc.com>
Subject VMTransport threading
Date Thu, 08 Dec 2016 15:10:21 GMT
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.

Mime
View raw message