[jboss-jira] [JBoss JIRA] (REMJMX-168) JMX proxy connection is released sooner than the client asks for closing it

[Ondrej Chaloupka (Jira)]

     [ https://issues.redhat.com/browse/REMJMX-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated REMJMX-168:
------------------------------------
    Description: 
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.

  was:
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.
When client creates a JMX proxy, then does not use it for a while and then it runs the JMX calls again such attempt 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.



> 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
>            Assignee: Darran Lofthouse
>            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/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.



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