[ https://issues.jboss.org/browse/WFLY-9073?page=com.atlassian.jira.plugin.... ] Piotr Krokowski edited comment on WFLY-9073 at 7/11/17 1:52 PM: ---------------------------------------------------------------- Forgive me, if my JVM knowledge is limited, but I'm not configuring any ThreadPoolExecutor, I'm not supplying any JVM parameters. In this plain example, I'm running java with it's defaults, and observe, that the number of connections spikes, beyond any reasonable limit. AFAIK the JMXConnectorFactory doesn't expose any API to inject any executor. I'm also not aware of any global switches for JVM that would configure such limits (correct me if I'm wrong, I might learn something). Please investigate the code, as I've highlighted in the description. The objects that are initialized during internalConnect are never cleaned up. EDIT: In other words, if there's any executor, it's internally encapsulated by the jboss-client implementation. I'm indirectly using it though JMX API. was (Author: piotr.krokowski.sabre): Forgive me, if my JVM knowledge is limited, but I'm not configuring any ThreadPoolExecutor, I'm not supplying any JVM parameters. In this plain example, I'm running java with it's defaults, and observe, that the number of connections spikes, beyond any reasonable limit. AFAIK the JMXConnectorFactory doesn't expose any API to inject any executor. I'm also not aware of any global switches for JVM that would configure such limits (correct me if I'm wrong, I might learn something). Please investigate the code, as I've highlighted in the description. The objects that are initialized during internalConnect are never cleaned up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)