I forgot to say that the same application in Wildfly 8/ HornetQ only uses five "HornetQ-client-global-threads".
I think this issue is currently discussed in [JBEAP-2947] OutOfMemory at HP_UX java during CDI TCK execution - JBoss Issue Tracker.
It seems that threads are reused but never die. To reduce the number of thread set thread-pool-max-size attribute in messaging-activemq subsystem.
Im sorry Miroslav, but it doesn't solve the problem.
If I set "thread-pool-max-size" (eg = 50) in messaging-activemq server, I change the amount of threads "ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl" from 30 (default) to 50 but I will still having 500 "ActiveMQ-client-global-threads".
I believe that (scheduled pool size, thread pool size and client pool size) need to begin with lower values on wildfly and be created when it is needed.
Maybe the queuing strategy used in Artemis ("Unbounded queues"), needs to be configured with a TTL or changed to a "Bounded queues" strategy.
Thanks Arial for this info! I suspect that pooled-connection-factory is responsible. I've suggested to allow corepoolthreadtimeout to be enabled as it seems there are reasons why "Unbounded queues" are used. It would solve this issue.
Currently the only way how to limit the size of the pool is to set -Dactivemq.artemis.client.global.thread.pool.max.size during start of EAP 7/Wildfly10 server like:
sh standalone.sh -c standalone-full-ha.xml -Dactivemq.artemis.client.global.thread.pool.max.size=30
Thanks Miroslav, good info!