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



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 {
            // Some processing
        } catch (XmppException e) {
            // Exception log
        } finally {
        // Sleep a bit


  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. jjoannes reporter

    Unfortunately the issue is still there (Java 8u151). Threads leak.png

    9h-9h21: server down

    9h21: server restarted

    GC forced many times...

  5. 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)

  6. jjoannes reporter

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

  7. 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.

  8. 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

  9. Christian Schudt repo owner

    Sorry, I've uploaded a wrong jar and potentially still had a bug in there. 0635936

    Please try again. New Snapshot available.

  10. Log in to comment