[jboss-jira] [JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection

[David Lloyd (Jira)]

    [ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985167#comment-13985167 ] 

David Lloyd commented on REMJMX-166:
------------------------------------

The problematic change was this line:

{code:java}
+                    group.setDaemon(true);
{code}

This causes the effect described in the bug.  The fix is to delete this line.

> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
>                 Key: REMJMX-166
>                 URL: https://issues.redhat.com/browse/REMJMX-166
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>    Affects Versions: 3.0.2.Final, 3.0.3.Final
>         Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
>            Reporter: Märt Bakhoff
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet: 
> {noformat}
> 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());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> 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)
> {noformat}
> 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 



--
This message was sent by Atlassian Jira
(v7.13.8#713008)