DO NOT REPLY [Bug 19684] New: - possible resource leak in NDC lazyRemove

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19684>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19684

possible resource leak in NDC lazyRemove 

           Summary: possible resource leak in NDC lazyRemove
           Product: Log4j
           Version: 1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Other
        AssignedTo: log4j-dev@jakarta.apache.org
        ReportedBy: wpitman@hotmail.com


log4j 1.2.8

I see that the NDC methods have a lazyRemove method to clean up context 
information for threads that have already died.  

I don't see how this code works correctly, as the lazyRemove method will stop 
after finding 4 threads that are alive, and does not traverse the entire set of 
NDC entries.  It is quite likely that the same 4 entries will be checked each 
time the lazyRemove is called (depending on the hash order, etc).

I run a server where threads are created and terminated on a regular basis, 
hopefully few or none of these will have failed to call NDC.remove().  My 
server also has a large number of steady state threads which also use NDC.  In 
such an environment, it does not appear that the lazyRemove() method will catch 
and clean up NDC data for expired threads.
  

Am I missing something, or is lazyRemove a bit too lazy?  

PS: Great job on log4j!

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org