Uploaded image for project: 'Remoting JMX'
  1. Remoting JMX
  2. REMJMX-166

IllegalThreadStateException after idle jmx connection

XMLWordPrintable

    • Workaround Exists
    • Hide

      Two workarounds are available: -

      1. Close the connection and recreate if it would be left idle for 60 seconds or more.
      2. Pass in an Executor within the configuration map using the key 'java.util.concurrent.Executor' this will then be used instead of the Remoting JMX thread management.
      Show
      Two workarounds are available: - Close the connection and recreate if it would be left idle for 60 seconds or more. Pass in an Executor within the configuration map using the key 'java.util.concurrent.Executor' this will then be used instead of the Remoting JMX thread management.

      Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet: 

      JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
  connector.connect();
  MBeanServerConnection beanServer = connector.getMBeanServerConnection();
  RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
  Thread.sleep(70_000);
  System.out.println("uptime: " + bean.getUptime());
}

      The following exception is always thrown:

      Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
	at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
	at java.lang.Thread.init(Thread.java:405)
	at java.lang.Thread.init(Thread.java:349)
	at java.lang.Thread.<init>(Thread.java:599)
	at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
	at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
	at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
	at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

      The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
      The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.

      The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f15bdefe445466e4

        1. REMJMX-160.jar
          3 kB
        2. REMJMX-166.jar
          3 kB

              rhn-support-bmaxwell Brad Maxwell
              mart.bakhoff Märt Bakhoff (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: