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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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.
