logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: Problem with String.intern() in CategoryKey
Date Tue, 24 May 2005 17:52:01 GMT
Vincent,

Can I ask you to enter a bug in the log4j bugzilla for this issue?  I don't
want it to slip away, and I think we should look at it for possible
fix/workaround in the 1.2.12 release.

http://issues.apache.org/bugzilla/enter_bug.cgi?product=Log4j

Thanks,
-Mark

> -----Original Message-----
> From: Vincent Shek [mailto:wsshek@taifook.com]
> Sent: Wednesday, May 11, 2005 6:56 PM
> To: Logging General
> Subject: RE: Problem with String.intern() in CategoryKey
> 
> Ceki,
> 
> I am not sure how I could control the number of intern() calls as I use
> the
> following line of code to log a statement:
> 
> org.apache.log4j.Logger.getLogger(String).log(String, Priority, Object,
> Throwable);
> 
> It shouldn't matter how many loggers I created in my application because
> the
> getLogger() method (it's actually Hierarchy.java) will always call New
> CategoryKey() which internalize the key each time I call the getLogger()
> function.  I didn't want to get a repository of loggers as I thought log4j
> will do that for me (but with the internalize problems).
> 
> Hopes this help,
> 
> Vincent
> 
> -----Original Message-----
> From: Ceki Gulcu [mailto:ceki@qos.ch]
> Sent: Thursday, May 12, 2005 12:30 AM
> To: Logging General; Logging General
> Subject: Re: Problem with String.intern() in CategoryKey
> 
> 
> 
> Vincent,
> 
> Thanks for this interesting report. I wonder how representative your
> example is. For example, you seem to internalize thousands if not millions
> of strings. Does this match your deployment scenario? In other words, how
> many loggers do you create?
> 
> At 11:11 5/11/2005, Vincent Shek wrote:
> >Hi all,
> >
> >I hesitate to send this email to this list as opposed to Bugzilla but I
> >would to get some opinion here first before I do so.  I am facing a
> strange
> >performance problem in our production environment when I use the
> conversion
> >pattern "C:L" to output class name and line number.  I DO expect the
> >performance to be slower but what I got was a gradual slowdown where our
> >application would literally slow down to a grinding halt after a few days
> of
> >running.  The application would get back to normal if I force it to run a
> >full GC.  After working with HP JVM engineer on this issue, the problem
> was
> >found to be the use of String.intern() in CategoryKey class AND the use
> of
> >java.lang.Throwable.getStackTraceElement() (to get line number and
> >classname).  The use of intern() causes the StringTable in JVM (in the
> >Permanent heap) to fill up very quickly as each call to
> Logger.getLogger()
> >will create an instance of CategoryKey object.  The method
> >getStackTraceElement()  will use the StringTable for lookup and it will
> take
> >longer for it to run as time goes. The StringTable may contain Strings
> which
> >are not live in the java program.  However, the collection of Strings in
> >StringTable is done only in Full GC.  That's the reason a Full GC
> recovered
> >the application performance. I have attached a sample program that will
> >reproduce the problem easily on any platforms using 1.4.2 JVM.
> >
> >My question to the logging group is whether the call to intern() is
> >necessary in creating the CategoryKey? Is it used to speed up hash
> lookup?
> >This seems like a VM bug but I doubt it will get fixed by Sun anytime
> soon
> >and I am worried that other system will experience the same problem I do.
> >(took us a few weeks to figure out the problem!)
> >
> >TIA for your help,
> >
> >Vincent Shek
> >
> >
> >This email is confidential. If you are not the intended recipient, please
> >notify the sender immediately.  The unauthorized use, disclosure,
> >dissemination or copying of this email is prohibited.  Emails are
> >susceptible to alteration and their integrity cannot be guaranteed. Tai
> Fook
> >Securities Group " Tai Fook" does not accept liability for damage caused
> by
> >this email.
> >
> >
> 
> --
> Ceki Gülcü
> 
>    The complete log4j manual: http://www.qos.ch/log4j/
> 
> 
> 
> This email is confidential. If you are not the intended recipient, please
> notify the sender immediately.  The unauthorized use, disclosure,
> dissemination or copying of this email is prohibited.  Emails are
> susceptible to alteration and their integrity cannot be guaranteed. Tai
> Fook
> Securities Group " Tai Fook" does not accept liability for damage caused
> by
> this email.


Mime
View raw message