Wildfly 10 Final indefinitely creating ActiveMQ-client-global-threads

[johntk]

I'm not sure I'm posting this in the right place, Mod please move If I. haven't

I have a `Wildfly AS` setup for JMS, I'm monitoring it with Jconsole and have noticed that before I even create a session on my `Consumer` or `Producer` the thread count is steadily increasing, I was previously using `Wildfly 9 final` for the same purpose, it's thread usage was steady even during use, but it had a memory leak which prompted me to upgrade. I'm running Wildly on a raspberry pi, so the resources this is wasting are valuable, if anyone could help me solve this I would be very grateful.

In `Jconsole` I can see:

    Thread-2(ActiveMQ-client-global-threads-3258368)

    Thread-4(ActiveMQ-client-global-threads-3258368)

    Thread-5(ActiveMQ-client-global-threads-3258368)

    Thread-6(ActiveMQ-client-global-threads-3258368)

    .

    .

    .

    Thread-16(ActiveMQ-client-global-threads-3258368)

How do I solve this problem? is there a setting I can change that is causing these threads to spawn, is there any more information I can take from `Jconsole` to help me resolve this?

[jbertram]

http://activemq.apache.org/artemis/docs/1.2.0/thread-pooling.html

[johntk]

Thanks for the response, after reading the link you posted I can see now that I need to setup client side thread management, so currently I'm using :

DEFAULT_CONNECTION_FACTORY=jms/RemoteConnectionFactory
DEFAULT_DESTINATION=java:/jms/queue/demoQueue
DEFAULT_USERNAME=mUserName
DEFAULT_PASSWORD=myPassword
INITIAL_CONTEXT_FACTORY=org.jboss.naming.remote.client.InitialContextFactory
PROVIDER_URL=http-remoting://myURL.com:8082

/** Lookup the queue object */

Queue queue = (Queue) context.lookup(props.getProperty("DEFAULT_DESTINATION"));

/** Lookup the queue connection factory */
ConnectionFactory connFactory = (ConnectionFactory) context.lookup(props.getProperty("DEFAULT_CONNECTION_FACTORY"));

try (javax.jms.Connection connection = connFactory.createConnection(props.getProperty("DEFAULT_USERNAME"), props.getProperty("DEFAULT_PASSWORD"));

   /** Create a queue session */
   Session queueSession = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

   /** Create a queue consumer */
   MessageConsumer msgConsumer = queueSession.createConsumer(queue)) {

   /** Set an asynchronous message listener */
   msgConsumer.setMessageListener(asyncReceiver);

   /** Set an asynchronous exception listener on the connection */
   connection.setExceptionListener(asyncReceiver);

   /** Start connection */
   connection.start();

}

Do I need to add the "ClientSessionFactory" configuration to my "standalone-full.xml" for  client side thread management

I can't access the .setUseGlobalPools(falase); from the RemoteConnectionFactory.

[jbertram]

You can set the necessary properties on the server-side in the XML configuration for your RemoteConnectionFactory, e.g.:

  <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" use-global-pools="false" thread-pool-max-size="10"/>

[johntk]

Thanks for your help with this, I was so close to figuring the problem, I couldn't figure out the right way to implement the  use-global-pools="false" thread-pool-max-size="10" inside my standalone.xml my system has been up for 24 hours now without a hitch.

This was important for me, thank you.

[lukaszpater]

Hello

I have the same problem when the consumer of the message is a Message Driven Bean. The server is slowly creating ActiveMQ-client-global-threads till it runs out of memory. Moreover all threads remain (and new are created) when redeploying the same application.

Many thanks

Lukasz

[jbertram]

If you're using an MDB then the corresponding configuration would be to specify the "useGlobalPools" and "threadPoolMaxSize" activation configuration properties on the MDB as appropriate.

[lukaszpater]

Many thanks Justin for your answer. Although it has helped (the threads are created much slower and there are no problems with redeployment) the system still keeps on creating ActiveMQ-client-global-threads. Each few minutes the system creates at the same time ActiveMQ-client-global-thread and ActiveMQ-remoting-thread. The latter one is removed after few seconds and the former one remains in the memory.

[jmesnil]

This might be related to 500 ActiveMQ-client-global-threads pool in Wildfly 10.0.0.Final