Heap memory usage of org.cometd.server.ServerSessionImpl objects

[cosimo]

Hi,

I'm investigating a case of OOM caused by heap exhaustion. Our servers normally run for months uninterrupted without issues. We had a few cases of servers stopping due to hard OOM errors, as in:

Heap dump file created [4620244762 bytes in 239.607 secs]
Exception in VM (AttachListener::init) : 
java.lang.OutOfMemoryError: Java heap space
2025-06-24 01:52:20
Full thread dump OpenJDK 64-Bit Server VM (21.0.7+6-Ubuntu-0ubuntu124.04 mixed mode, sharing):
...

No Java expert here. I've been looking into the heap dump with MAT, and found that the 3GB of heap were 99.9% held up by org.cometd.server.ServerSessionImpl instances and related retained heap. When diving into the dump data, I can see that each of these objects was storing a long queue of ServerMessageImpl objects, presumably (my hypotesis here) not acknowledged or in some other way "pending". Other internal evidence suggests this could related to some sort of malicious/spammy client traffic.

Before I investigate more about this, and how to reproduce it consistently, would there be any circumstances where the ServerSessionImpl objects retain ServerMessageImpl instances for an abnormal amount of time? Would there be a way to limit this behavior?

In other words: is it possible to cause a CometD server to blow up its heap memory usage by firing a lot of clients towards it, and then somehow stall reception of messages, so they would be retained at the server level?

This sort of malfunction is very rare, but it does cause OOM and thus complete server breakdown, hence I'm looking into what's possible to do to understand more about it and prevent it.

Any tips or guidance would be appreciated, thanks 🙏

We're running Java CometD server 8.0.6 on Jetty 12.0.15, JVM is OpenJDK 21 on Ubuntu 24.04.

[sbordet]

First of all, have you tried to latest Jetty and CometD?

Are you using HTTP/2?

Related to the issue you describe here, there is #1770, but I see that it should be fixed since 8.0.2.

Can you share the heap dump?
Or at least I am interested seeing all the fields of a ServerSessionImpl object that has a lot of messages in its queue -- you can take a screenshot from MAT and post it here?

[cosimo]

Thanks for looking into this.

Answers:

• We haven't tried the latest Jetty and CometD yet. Looking at the changelog, I can't see anything related to this issue. We can still schedule an update in the next weeks, but not immediately.
• We are using HTTP/2 in our stack, but we switch to HTTP/1.1 when talking to the CometD servers. We use the proxy_http_version 1.1; directive in our nginx configuration towards the comet servers.
• Suspended sessions are leaked with HTTP/2 reset #1770 seems relevant, thanks for pointing that out.
• Screenshot is attached, I can perhaps share the heap dump file as well, although it's 4GB+.

[sbordet]

Unfortunately, the screenshot only shows 25 out of 32 fields (see left panel) and I really need at least 2 of the 7 that are missing.

Can you also highlight, for that ServerSessionImpl, the field AcknowledgedMessagesSessionExtension._lastBatch?

[cosimo]

Yes, sorry. Here is the expanded view:

The _lastBatch attribute is equal to 1 for this particular ServerSessionImpl -> AcknowledgedMessagesSessionExtension instance. I tried looking up other ServerSessionImpl instances, and they all have _lastBatch value of 1.

[sbordet]

@cosimo what client do you use?

[cosimo]

Generally, we're using the CometD javascript library (8.0.x) on the frontend client side, although we're exposed to all sorts of bots and unorthodox clients, so it's not possible to exclude that this was the result of some non-well behaved clients.

[sbordet]

This discussion led to issue #2117, fixed in CometD 8.0.9.