vp340 commented on code in PR #3521: URL: https://github.com/apache/cxf/pull/3521#discussion_r4175206394
########## rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingOutInterceptor.java: ########## Review Comment: > Sorry about that @vp340 , I just checked the latest revision @reta no problems :) . > Fair point, I think we could fix that by guarding CachedOutputStream::close() - once closed, it should not be closed again (and invoke the callbacks), that should fix it for everyone, not only for logging interceptor U mean to use a similar logic as the OneTimeLoggingCallback with a boolean that guards if it's already close? I think we need to be careful about that. In my case the LoggingCallback was called 2 times... So the first one logged, but encounter some sort of error after... cause the cos was never unregister from the cachedOutputStreamCleaner. So if we put a guard not to close the cos a second time... we could reintroduce the tmp file problem nullifying the purpuse of the clean() of DelayedCachedOutputStreamCleaner (that will call a .close() method that does nothing). I was searching the root cause, but I couldn't reproduce my scenario a second time (Logging twice + memory leak). I only have the log of that happening. The solutions in these PRs are only for that. But in the Jira ticket when I tryed to reproduce that again I obtained a 2nd scenario for which I haven't found a workaround: the .close() is never called the first time. (so no log) ... and after N minutes DelayedCachedOutputStreamCleaner call .close (so delayed log ... + memory leak) . I suggest to tackle one problem at a time ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
