Mailing-List: contact general-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Logging General" <general@logging.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: 
 <ED05A0F2CAC79244A0FF6D820DD1272D56415D@tfsmail.tfprod.taifook.com>
From: Vincent Shek <wsshek@taifook.com>
To: Logging General <general@logging.apache.org>
Subject: RE: Problem with String.intern() in CategoryKey
Date: Thu, 12 May 2005 09:55:35 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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=20
example is. For example, you seem to internalize thousands if not =
millions=20
of strings. Does this match your deployment scenario? In other words, =
how=20
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.
>
>

--=20
Ceki G=FClc=FC

   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.