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

            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: