Memory leak on connection failure

[jjoannes]

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

[Christian Schudt]

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

[jjoannes]

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:

[Christian Schudt]

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.

[jjoannes]

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

9h-9h21: server down

9h21: server restarted

GC forced many times...

[Christian Schudt]

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)

[jjoannes]

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

[Christian Schudt]

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.

[jjoannes]

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

[Christian Schudt]

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

Please try again. New Snapshot available.

[jjoannes]

That's OK now.

[Christian Schudt]

Fix version: 0.7.5