Memory leak on connection failure

Issue #122 closed
jjoannes
created an issue

Hi Christian,

While trying, in a loop, to connect (WebSocket) to a XMPP server which is actually down, I noticed that the number of XmppSession instances increased steadily (checked after garbage collecting of course) as well as the number of threads ("WebSocket send thread"). When the XMPP server is up and running all is fine.

Babbler version: 0.7.5-SNAPSHOT

Thanks,

Jacques

Comments (13)

  1. Christian Schudt repo owner

    Do you have some sample code? Having multiple instances of XmppSession can only happen, if you create multiples, e.g. with XmppClient.create(). Maybe you should only create one session and call connect() in the loop? Do you call close() on the XmppSession object if an exception during connect() occurs??

  2. jjoannes reporter

    I was not clear enough, the loop closes the connection. Due to the nature/design of the program it would be quite difficult to bypass the multiple XmppClient.create() and, by the way, that doesn't cause any leak when the connection is successful.

    for (...) {
        xmppClient = XmppClient.create(...);
    
        try {
            xmppClient.connect();
            xmppClient.login(...);
            // Some processing
        } catch (XmppException e) {
            // Exception log
        } finally {
            xmppClient.close();
        }
    
        // Sleep a bit
    }
    

    Pseudo-code:

  3. Christian Schudt repo owner

    I've tried to reproduce the issue with 1000 iterations, but couldn't see any leaks. (Used Java 8u60 and jvisualvm to analyze the heap).

    However, from code analysis and debugging I've seen, that the close() method is not called, if an exception occurred. It means, the created ExecutorService is not immediately shutdown. I think the VM waits a little bit and GCs non-active executor services, maybe that's what you are seeing.

    I've tried to solve the issue with 226b443 (although I never really saw the issue). But maybe you can test it? I've uplodaded a new 0.7.5-SNAPSHOT.

  4. Christian Schudt repo owner

    Do you have the ability to debug? Is the WebSocketConnection#close() method called? Do you add any listeners before connect()?

    Or can you check the cause with jsvisualvm? ("Show nearest GC root" on an XmppClient instance)

  5. jjoannes reporter

    I think I found the culprit... I removed the "pingInterval(...)" when calling "WebSocketConnectionConfiguration.builder()" and the leak disappeared.

  6. Christian Schudt repo owner

    I looked into it again, but I am pretty sure, you didn't test with latest snapshot. I could reproduce the issue when setting the pingInterval, but only with code before my fix (226b443).

    Anyway, I optimized the code a bit more and deployed a new snapshot. Could you please try again? Maybe with "mvn clean install -U" to really download the latest snapshot.

  7. jjoannes reporter

    You're right, I didn't have the latest release. Which fixes the bug indeed, but I noticed that the "connection.close()" is now very, very slow (more than 10 seconds instead of tens of ms) compared to the last 7.0.5 I used (don't know exactly which one), which is a big issue for my program. It is OK in 0.7.4 and at least in 0.7.5-20171109.191817-2

  8. Log in to comment