-
Bug
-
Resolution: Done
-
Major
-
None
Couple of memory leaks were reported by QE, which manifest when reloading the app container (JBEAP-25588). This ticket is about the Undertow related class instances.
Following class instances are created at each app server reload, but are never garbage collected:
| 386752 bytes (+1344)| 6043 instances (+21)|io.undertow.server.DefaultByteBufferPool | 142104 bytes (+504)| 5921 instances (+21)|io.undertow.server.DefaultByteBufferPool$ThreadLocalData
DefaultByteBufferPool defines a non-static ThreadLocal<ThreadLocalData> threadLocalCache field.
The threads where ThreadLocalData instances are stored into the threadLocalCache fields are the "MSC service threads". These threads survive the server reloads.
To me it looks that the reason why above instances are not garbage collected is that the ThreadLocalData instance references are kept in the Thread.threadLocals map of the MSC service threads (i.e. the map where ThreadLocal values are stored).
- causes
-
UNDERTOW-2389 DefaultByteBufferPool leaks buffers for released threads
- Resolved
-
JBEAP-27062 [GSS](7.4.z) UNDERTOW-2389/UNDERTOW-2385 - DefaultByteBufferPool leaks buffers for released threads
- Closed
-
JBEAP-27063 [GSS](8.0.z) UNDERTOW-2389/2385 - DefaultByteBufferPool leaks buffers for released threads
- Closed
- is cloned by
-
JBEAP-25835 (8.0.z) UNDERTOW-2309 Possible memory leak in DefaultByteBufferPool
- Closed
-
JBEAP-25836 (7.4.z) UNDERTOW-2309 Possible memory leak in DefaultByteBufferPool
- Closed
- is incorporated by
-
WFCORE-6695 CVE-2023-4639 Upgrade Undertow to 2.3.11.Final
- Resolved