vp340 commented on code in PR #3521:
URL: https://github.com/apache/cxf/pull/3521#discussion_r4175639035


##########
rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingOutInterceptor.java:
##########


Review Comment:
   @reta U're welcome. 
   I know the situation it's quite difficult and confusing. 
   We need to tackle the two scenario separately. 
   
   Maybe I found the root cause for the 2nd scenario ((memory leak in queue + 
logging only after N minutes when DelayedCachedOutputStreamCleaner  does its 
clean). 
   It could be how tomcat handle the outputStream after a java.io.IOException: 
Connection reset by peer . 
   In CoyoteOutputStream.class they doesn't close the stream after that 
exception while write()ing ....(it seams at least) and I don't have sufficient 
knowledge to say they should.
   Pls see the last comment in the Jira ticket. for details (stack and image) .
   
   If we clear up that problem then it remains only the 1st scenario (memory 
leak in queue + double logging). 
   As I can't reproduce the problem we can't debug the root cause, but we can 
threat it as a black box and do a workaround. 
   We already know for sure that the OutputStream is close. (first callback 
log). For some unknown reason it remains in the queue and so it create possible 
memoryLeak (reference to LoggingCallback ..and so to Message and others) and do 
the double partial log when close. 
   I think that for this 1st scenario https://github.com/apache/cxf/pull/3521 
or https://github.com/apache/cxf/pull/3535 should do the job, cause they solve 
all the 2 problems. 
   They only both say "ehi this LoggingCallback should be called only once" (so 
they are conceptually correct). 
   If I had to chose I would go with https://github.com/apache/cxf/pull/3535 . 
(it seems more clean to me). 
   
   Let me know what U think. 
   Now I'll go to bed (here it's 3 a.m. so...) ... I hope I won't have 
nightmares about this aahaha. 
   
   See U tomorrow. 



-- 
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]

Reply via email to