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

IllegalThreadStateException after idle jmx connection

    XMLWordPrintable

    Details

    • Workaround:
      Workaround Exists
    • Workaround Description:
      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.

      Description

      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

        Attachments

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

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: