logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19684] - possible resource leak in NDC lazyRemove
Date Wed, 07 May 2003 17:16:21 GMT
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

ceki@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From ceki@apache.org  2003-05-07 17:16 -------

Very nice try but I remain unconvinced. :-)

When you create 100 threads that never die and 5 that leak, catching leaking 
theads is more difficult because they are proportionally few. However, if the 
number of leaking threads increases then the probability of catching them 
increases. This is actually demonstrated by NDCTester.

So running 

 java -cp log4j.jar  NDCTester 100 180 100

will work as expected. 

As the number of leaking threads increases so does the probability of lazily 
catching and removing them.

One could devise fiendish cases to defeat the lazy removal algoritm such that 
threads land in specific placed in 'ht' hashmap. But these contrived cases will 
heavily depend on the Hashmap implementation and the implementation of the 
Thread.hashcode method of the JDK being used. I think that for any real world 
system the existing lazy removal algorithm will work just fine.

Nice but no cigar. :-)

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


Mime
View raw message