[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: DO NOT REPLY [Bug 50486] Memoryleak - org.apache.log4j.helpers.ThreadLocalMap Ralph Goers Fri Feb 03 08:02:00 2012

I see no harm in it as the next put will just create a new Hashtable, which 
shouldn't be all that expensive in new JVMs.  I really am not crazy about it 
using Hashtable as I really don't see why a Map with synchronized methods is 
required. But it is probably best to just leave well enough alone on that issue 
and it isn't necessary to fix this problem.  FWIW, Logback doesn't call 
remove() when the map is empty and at the moment neither does Log4j 2, but I 
think I'm going to change it to do it.


On Jan 25, 2012, at 2:33 PM, Christian Grobmeier wrote:

> Hello fellow devs,
> can one of you give me a hint on this? As you know i am just helping
> out with log4j and so I am glad about comments from more experienced
> people, esp, in this case. I really would like to close this issue
> now.
> Is it possible to let remove() call clear()?
> Cheers
> Christian
> On Wed, Jan 25, 2012 at 11:10 PM,  <[EMAIL PROTECTED]> wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
>> --- Comment #12 from [EMAIL PROTECTED] 2012-01-25 22:10:41 UTC ---
>> Ok, the patch was accepted, modified and applied I get that.
>> a) Shouldn't this ticket be marked as 'resolved'?
>> b) What's the ETA for 1.2.17?
>> Also, I believe there's a second issue. The way it's implemented right know
>> clients must explicitly call MDC.clear(). Couldn't/shouldn't remove() call
>> clear() internally once the last item was removed()?
>> How do clients know when to call clear()? In a request processing chain (e.g.
>> Servlet filter) several parties may write items and each one of them is
>> responsible to call remove() for the items it added. On the way it items are
>> added, on the way out they're removed in reverse order. And the last guy 
>> closes
>> the door i.e. calls clear(). However, how does a client know that he's the
>> last?
>> --
>> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You are the assignee for the bug.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]