[ 
https://issues.apache.org/jira/browse/CXF-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033042#comment-18033042
 ] 

Andriy Redko commented on CXF-9171:
-----------------------------------

Thanks [~aogburn] , opened up https://github.com/apache/cxf/pull/2684

 
The fix introduces 2 major improvements:
 * delays the timer creation till at least one registration for cleanup happens
 * introduces a cleanup strategy with new SingleTimerDelayedCleaner 
implementation for applications that may create a large number of {{Bus}} 
instances (based on the patch for the issue)
 * additional {{Bus}} property to select the appropriate strategy
The default strategy is lazy (in respect of timers now), but you could opt-in 
for  another strategy (based on the patch submitted, thank you). Please note 
the original patch has issues implementing clean() and forceClean() (more 
specifically, drainTo will only drain expired entries for DelayedQueue). Thank 
you.

> 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
>            Assignee: Andriy Redko
>            Priority: Major
>             Fix For: 4.1.4, 3.6.9, 4.0.10
>
>         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)

Reply via email to