Skip to content

Conversation

@reta
Copy link
Member

@reta reta commented Oct 26, 2025

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

@aogburn
Copy link

aogburn commented Oct 29, 2025

And for the DelayedCachedOutputStreamCleaner currently, it still becomes leaky after 1 registered closeable for any bus that is not shutdown. So if it had a means of auto-closing its timer some time after the last registered closeable that would be better.

@reta
Copy link
Member Author

reta commented Oct 30, 2025

And for the DelayedCachedOutputStreamCleaner currently, it still becomes leaky after 1 registered closeable for any bus that is not shutdown. So if it had a means of auto-closing its timer some time after the last registered closeable that would be better.

Thank you @aogburn , that is correct, but I think we should stay pragmatic here, if majority of applications has only one Bus instance, having a single timer that triggers every 30 mins is more than tolerable I believe.

@aogburn
Copy link

aogburn commented Oct 31, 2025

And for the DelayedCachedOutputStreamCleaner currently, it still becomes leaky after 1 registered closeable for any bus that is not shutdown. So if it had a means of auto-closing its timer some time after the last registered closeable that would be better.

Thank you @aogburn , that is correct, but I think we should stay pragmatic here, if majority of applications has only one Bus instance, having a single timer that triggers every 30 mins is more than tolerable I believe.

Thanks for the revisions. The DefaultDelayedCleaner timer thread creation is now truly lazy in my tests and thread/classloader leaks in my tests with multiple busses over time are corrected by the SingleTimerDelayedCleaner.

@reta reta merged commit 1ce9fe1 into apache:main Nov 1, 2025
5 of 6 checks passed
reta added a commit that referenced this pull request Nov 1, 2025
…VE-2025-23184 fix (#2684)

* CXF-9171: DelayedCachedOutputStreamCleaner thread accumulation after CVE-2025-23184 fix

* Address code review comments

(cherry picked from commit 1ce9fe1)
reta added a commit that referenced this pull request Nov 1, 2025
…VE-2025-23184 fix (#2684)

* CXF-9171: DelayedCachedOutputStreamCleaner thread accumulation after CVE-2025-23184 fix

* Address code review comments

(cherry picked from commit 1ce9fe1)
(cherry picked from commit 38adf23)
@ppalaga
Copy link
Contributor

ppalaga commented Nov 3, 2025

This is causing https://issues.apache.org/jira/browse/CXF-9172
Could we perhaps create the Timer lazily, when the first closeable is registered?

@ppalaga
Copy link
Contributor

ppalaga commented Nov 3, 2025

Something like this? #2706

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants