]
Darran Lofthouse commented on REMJMX-168:
-----------------------------------------
[~ochaloup] Could you please check if this still happens, there was another bug reported
in relation to REMJMX-160 which has now been fixed
JMX proxy connection is released sooner than the client asks for
closing it
---------------------------------------------------------------------------
Key: REMJMX-168
URL:
https://issues.redhat.com/browse/REMJMX-168
Project: Remoting JMX
Issue Type: Bug
Components: Connection
Affects Versions: 3.0.2.Final, 3.0.3.Final
Reporter: Ondrej Chaloupka
Priority: Major
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/or...)
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....).
When I used the {{Executors.newFixedThreadPool}}
(
https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...)
the issue disappeared.