vp340 commented on code in PR #3521: URL: https://github.com/apache/cxf/pull/3521#discussion_r4188355487
########## rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingOutInterceptor.java: ########## Review Comment: Hi @reta, I'm here again to bother U. This time with good news. :) So: ------ **_1st Scenario (double log + memory leak)_** Today at work I retry locally using version 4.0.6 and I was easily able to reproduce again the issue. ALL the LoggingOutputStream were not deregister, ...and than queue of cosCleaner was full and logged after minutes as expected. So this problem is the one U already fixed in 4.0.7 as I suspected yesterday. Sorry for the false alarm, but as I saw that happen I urge to open the ticket. So we can label this problem as 'Archived'. ------ **_2nd Scenario (log delayed + memory leak) (still present also in 4.0.11)_** So I only have time to do a quick test. I setup my java client to reset on purpose the connection and print the resulting response in InputStream (incoming response). Here the result: <img width="1783" height="269" alt="image" src="https://github.com/user-attachments/assets/bdffa579-2deb-407d-a858-1be74189aafe"; /> So I think that those bytes that are in the CachedOutputStream **should** be log because this is proof we actually sent them. A owner of his server should be able to see what his service produce and sent onto the http socket... for audit purpose! Whether the client processes those bytes or discards them afterward is outside our scope, but on the server side, having a complete audit trail I think it'is crucial. For example (a little bit borderline) a malicious client could call and reset the connection to receive the first bytes of the response and have no response trace on the server side. So in this case I think we should modify like https://github.com/apache/cxf/pull/3541 I locally build a 4.0.12-SNAPSHOT with that solution. The memory leak is vanished. (empty queue). The logging is: > 05/10/2026 21:53:09.226 INFO [http-nio-8080-exec-2] org.apache.cxf.services.ExampleServicePortType_v1.RESP_OUT - RESP_OUT Address: http://localhost:8080/example/cxf/ExampleService_v1 Content-Type: text/xml ResponseCode: 200 ExchangeId: 0357f765-bb44-4680-aaf4-84f8ee4ce68c ServiceName: ExampleService_v1 PortName: ExampleServicePortType_v1 PortTypeName: ExampleServicePortType_v1 Headers: {} Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.or...etc... 05/10/2026 21:53:09.230 WARN [http-nio-8080-exec-2] org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {http://ws.schema/example/v1}ExampleService_v1#{http://ws.schema/example/v1}pluto has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: java.io.IOException: Connection reset by peer at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(A Let me know what U think. Feel free to modify or add something if U don't find it suitable. I enable "allow modify by maintainers". Today I didn't find the time to work on my other idea. That solution could be more general, but way more difficult to implement. And not to overturn the state of the art of CachedOutputStream I would like to implement the interface CachedOutputStreamCleaner to do so and create another clean strategy to choose from. I need more time to think about it and implement it. Meanwhile let me know if U want to pursue https://github.com/apache/cxf/pull/3541 Have a great evening! -- 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]
