[
https://issues.apache.org/jira/browse/CXF-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032780#comment-18032780
]
Aaron Ogburn commented on CXF-9171:
-----------------------------------
Thanks [~reta]. The created thread would by default inherit the
contextClassLoader upon creation so that could be a point of improvement.
But if we minimize the thread creation and more lazily schedule the timer tasks
only when needed and cancel the timer tasks as possible if closeables are
unregistered, then this also minimizes thread growth along with any classloader
leaks from them. I attached a patch [~opalka] and I worked towards for that
and tested using a single static timer thread and this corrects any potential
thread growth (keeping to the one shared static Timer thread) and associated
context loader references.
> DelayedCachedOutputStreamCleaner thread accumulation after CVE-2025-23184 fix
> -----------------------------------------------------------------------------
>
> Key: CXF-9171
> URL: https://issues.apache.org/jira/browse/CXF-9171
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 4.1.0, 3.5.10, 3.6.5, 4.0.6
> Environment: JBoss/Wildfly
> Reporter: Aaron Ogburn
> Priority: Major
> Attachments: CXF-9171.patch
>
>
> After the CVE-2025-23184 fix (CXF-7396), DelayedCachedOutputStreamCleaner
> timer threads can be problematic and can contribute to unwanted thread growth
> and possibly classloader leaks potentially to the point of thread OOMEs or
> metaspace OOMEs. This now creates a unique Timer and thread for every bus
> instance created just to handle a single 30 min default interval task even if
> there is no closeable yet registered so this seems excessive and a bus is a
> much more leaky object as a result. The created Timer thread will also
> inherit contextClassLoaders and that may then preserve some app classloader
> reference to possibly influence additional classloader leaks.
> For instance, in the context of WildFly/JBoss it maintains a WeakHashMap
> storing busses with a bus keyed off a classloader. But the bus can now
> maintain a strong reference to that classloader through the
> DelayedCachedOutputStreamCleaner TimerThread's contextClassLoader so this
> WeakHashMap can no longer self clean:
> {code:java}
> Class Name
> | Ref. Objects
> | Shallow Heap | Ref. Shallow Heap | Retained Heap
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> [5] class org.jboss.wsf.stack.cxf.client.configuration.JBossWSBusFactory @
> 0x5d513a898 |
> 1 | 8 | 96 | 24,503,336
> '- classLoaderBusses java.util.WeakHashMap @ 0x5f846cd30
> | 1
> | 48 | 96 | 24,503,328
> '- table java.util.WeakHashMap$Entry[32] @ 0x5d6af4dd0
> | 1
> | 144 | 96 | 24,503,232
> '- [28] java.util.WeakHashMap$Entry @ 0x5d6af4e60
> | 1
> | 40 | 96 | 3,793,016
> '- value org.apache.cxf.bus.extension.ExtensionManagerBus @
> 0x5d6af4e88 |
> 1 | 56 | 96 | 3,792,976
> '- extensions java.util.concurrent.ConcurrentHashMap @
> 0x5d6af5080 |
> 1 | 64 | 96 | 3,616
> '- table java.util.concurrent.ConcurrentHashMap$Node[64] @
> 0x5d6af50c0 |
> 1 | 272 | 96 | 3,552
> '- [2] java.util.concurrent.ConcurrentHashMap$Node @
> 0x5d6e93778 |
> 1 | 32 | 96 | 32
> '- val
> org.apache.cxf.io.DelayedCachedOutputStreamCleaner @ 0x5d6e89398
> | 1 | 24 |
> 96 | 256
> '- cleaner
> org.apache.cxf.io.DelayedCachedOutputStreamCleaner$DelayedCleanerImpl @
> 0x5d6e893b0 | 1 | 32 |
> 96 | 232
> '- timer java.util.Timer @ 0x5d6e89498
> | 1
> | 24 | 96 | 720
> '- thread java.util.TimerThread @ 0x5cf230188
> DelayedCachedOutputStreamCleaner | 1
> | 128 | 96 | 144
> '- contextClassLoader
> org.jboss.ws.common.utils.DelegateClassLoader @ 0x5cf1e9b68
> | 1 | 72 | 96 | 560
> '- parent, parent my.app.ClassLoader @
> 0x5cf1e8af0| 1 | 96 | 96 | 11,565,128
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
