logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Shek <wss...@taifook.com>
Subject RE: Problem with String.intern() in CategoryKey
Date Wed, 25 May 2005 02:42:00 GMT
Mark,

I will post a bug to bugzilla shortly. In the mean time, I adopt the use of
apache common logging API which will cache each instance of logger and
eliminate the need to call Logger.getLogger() which in turn eliminate the
need for CategoryKey to call String.intern().

Vincent

-----Original Message-----
From: Mark Womack [mailto:womack@adobe.com]
Sent: Wednesday, May 25, 2005 1:52 AM
To: 'Logging General'; wsshek@taifook.com
Subject: RE: Problem with String.intern() in CategoryKey


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.


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