Bug 1828824

Summary:	[GSS](6.4.z) REMJMX-166 - IllegalThreadStateException after idle jmx connection
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Brad Maxwell <bmaxwell>
Component:	JMX	Assignee:	Romain Pelisse <rpelisse>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4.22	CC:	darran.lofthouse, hrupp, pmackay, rpelisse
Target Milestone:	---
Target Release:	EAP 6.4.23
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-02-10 04:00:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1699388, 1708467

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.