Return-Path: Delivered-To: apmail-logging-general-archive@www.apache.org Received: (qmail 16303 invoked from network); 25 May 2005 02:42:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2005 02:42:34 -0000 Received: (qmail 97106 invoked by uid 500); 25 May 2005 02:42:33 -0000 Delivered-To: apmail-logging-general-archive@logging.apache.org Received: (qmail 97057 invoked by uid 500); 25 May 2005 02:42:32 -0000 Mailing-List: contact general-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Logging General" List-Id: Delivered-To: mailing list general@logging.apache.org Received: (qmail 97039 invoked by uid 99); 25 May 2005 02:42:32 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from Unknown (HELO server.taifook.net) (202.22.244.17) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 24 May 2005 19:42:31 -0700 Received: from tfsmail.tfprod.taifook.com ([192.168.96.154]) by server.taifook.net (8.11.7/8.11.7) with ESMTP id j4P2gRS31625 for ; Wed, 25 May 2005 10:42:27 +0800 Received: by tfsmail.tfprod.taifook.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 May 2005 10:42:07 +0800 Message-ID: From: Vincent Shek To: "'Logging General'" Subject: RE: Problem with String.intern() in CategoryKey Date: Wed, 25 May 2005 10:42:00 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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.