Bug 1828824 - [GSS](6.4.z) REMJMX-166 - IllegalThreadStateException after idle jmx connection
Summary: [GSS](6.4.z) REMJMX-166 - IllegalThreadStateException after idle jmx connection
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JMX
Version: 6.4.22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: EAP 6.4.23
Assignee: Romain Pelisse
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: eap6423-payload 1708467
TreeView+ depends on / blocked
 
Reported: 2020-04-28 12:45 UTC by Brad Maxwell
Modified: 2025-02-10 04:00 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 04:00:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker REMJMX-166 0 Blocker Resolved IllegalThreadStateException after idle jmx connection 2020-09-22 21:00:00 UTC

Description Brad Maxwell 2020-04-28 12:45:59 UTC
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

Comment 4 Peter Mackay 2020-06-30 11:48:13 UTC
Verified with EAP 6.4.23.CP.CR2

Comment 6 Red Hat Bugzilla 2025-02-10 04:00:13 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


Note You need to log in before you can comment on or make changes to this bug.