0 Replies Latest reply on Oct 12, 2017 9:44 PM by George Turner

    Help finding which client is not cleaning up JMS connection

    George Turner Newbie

      Below is a message that we get in our server, repeatedly, and I have been unable to determine the cause.  We have changed every setting in the book, so it boils down to a bad client, but the only thing in this message that help identify the client is the IP and "port number"?

      Does someone have additional ways to debug this?  We are on RHEL 7 and I have tried using netstat -cap (-c continuous mode) to create a log of used port per pid, and then when I see the message, check the log for the port, and it is never there.

      We really need to find this, and I would love some help.

       

      Please do not recite documentation about the noted settings in the message.  Been there, done that!

       

      Thanks in advance.

      Gene

       

       

      2017-10-06 00:56:47,479 WARN  [org.apache.activemq.artemis.core.client] (activemq-failure-check-thread) AMQ212037: Connection failure has been detected: AMQ119014: Did not receive data from /10.10.10.29:19812. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]

       

      UPDATE:  I just completed a grueling day of trying every option I could find.  I even replaced the Artemis module with version 1.3 and it made no difference.  I set TTL and ClientCheckPeriod to different combinations of -1, very high TTL with very low CheckPeriod, still no difference.  I added MORE logging to the client to confirm close was being called.  I even made it call stop before calling close.  Looking at the RemotingServiceImpl class where this check is made, there is a check for "failureListeners".  We call "setExceptionListener(null)" before we close the connection, and I am not sure how our exceptionListener class gets translated to a failureListener, but my next try is to NOT add an exceptionListener and see if that has any affect.