Uploaded image for project: 'Remoting JMX'
  1. Remoting JMX
  2. REMJMX-168

JMX proxy connection is released sooner than the client asks for closing it

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 3.0.2.Final, 3.0.3.Final
    • 3.0.4.Final
    • Connection
    • None

    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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: