4 Replies Latest reply on May 4, 2009 4:09 AM by Jeff Mesnil

    ReplicateConnectionFailureTest failure on CI server

    Jeff Mesnil Master

      after I committed a fix for JBMESSAGING-1421 (r6641), ReplicateConnectionFailureTest.testFailConnection() is failing.

      I think the reason is the connection is no longer cleaned up when it is closed but only when the connection TTL is hit.
      However, the replicating connection is not checked by the remoting service impl FailedConnectionsTask and nobody will realize it must be cleaned up and we will never call fail() on it.

      I need to check that it is indeed what it happening.

      The fix would be to ensure that the replication connection is also checked by the RemotingService's FailedConnectionsTask but I'm not sure to see the whole implications wrt to replication.

        • 1. Re: ReplicateConnectionFailureTest failure on CI server
          Clebert Suconic Master

          I think this may be related:

          I'm at the moment chasing a leakage on Connections.

          one of the places that I found was ConnectionManagerImpl.pingExecutor. If I called ConnectionManagerImpl.recreatePingExecutor() I could get a lot of references cleared.

          So, I also think connections are not being cleaned up somehow.

          • 2. Re: ReplicateConnectionFailureTest failure on CI server
            Tim Fox Master

            Jeff, I'm a bit confused about your changes for 1421:

            RemotingServiceImpl:
            
            public void connectionDestroyed(final Object connectionID)
             {
             // We DO NOT destroy the connection when this event is received.
             // Instead, the connection will be cleaned up when the connection TTL
             // is hit in FailedConnectionsTask.
             }
            


            Does this mean that if I create a core session, close it properly and exit, the server side remoting connection won't be closed until TTL?

            If so, that's not correct.

            If the client closes it's connections properly then the server side resources must be immediately cleared up.

            The server side connection should only not be closed immediately if the client exits without closing it's stuff properly.

            Otherwise you'll end up with resource build up on the server, and a potential for DoS attack by a client by simple creating and closing connections quickly.

            • 3. Re: ReplicateConnectionFailureTest failure on CI server
              Tim Fox Master

              I fixed this now anyway

              • 4. Re: ReplicateConnectionFailureTest failure on CI server
                Jeff Mesnil Master

                 

                "timfox" wrote:

                Does this mean that if I create a core session, close it properly and exit, the server side remoting connection won't be closed until TTL?


                Yes, that's the case.

                We talked about it in IRC (http://www.antwerkz.com/javabot/javabot/home/3/%23jbossmessaging/2/29/1/04/0/2009/)

                <jmesnil> there are a few failing tests which expects the server resources
                 to be cleaned up immediately after the connection is closed.
                 but now I've to wait for the connection TTL [11:12]
                <jmesnil> this can lead to resources congestion: a "unclean" client which
                 never closes its connection will leave resources on the server
                 for 5 minutes for each connection [11:12]
                <jbossfox> jmesnil: well.. resources should normally be cleaned up
                 immediately since, a good client should close its connections
                


                If we want to close server resources immediately when we're notified that the connection is destroyed, we must first know if the connection was closed properly or not.
                To know for sure the connection is closed properly, the client should send a LAST packet, the connection should be closed from the server and the client be disconnected.