We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160.

What we hit:
It seems the JMX connection is closed too soon - before the client decides to release it.
The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails.

Our test does:

• The transaction recovery test creates the JMX proxy at some point to verify content of object store.
• Then there is some idle time where the JMX proxy is not utilized.
• When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails.

From investigation it seems that it could be caused by the fact that Executors.newCachedThreadPool (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/org/jboss/remotingjmx/protocol/v2/ClientExecutorManager.java#L50) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool--).
When I used the Executors.newFixedThreadPool (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad03a08d88b9bec8c) the issue disappeared.