You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Naveen <na...@yahoo.com> on 2006/06/07 16:45:20 UTC
Log4j String buffer memory Leak.
Hello all,
Iam not sure if there is really amemory leak in Log4jLogger. We use Mercury diagnosis tool to find the memory leak and the reports show all the string buffers being held up at
1. org.apache.log4j.Logger.debug
2. org.apache.log4j.Logger.info
this is one of the call we make
logger.debug(connectionID + "-" + message);
logger is an instance of Log4j.Logger and connectionID,message are strings
i know appending strings will internally create StrinBuffers but our memory reports show string buffers are never cleared which are areated during that call.
any help is highly appreciated.
Thanks,
Naveen.
Naveen
It only takes a moment to be kind, but the results can be everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Log4j String buffer memory Leak.
Posted by Sandy McArthur <sa...@apache.org>.
On 6/7/06, Naveen <na...@yahoo.com> wrote:
> Thanks a lot sandy and Oliver ..
> but the issue remains...Mercury Diagnosis tools reports lot of Sting Buffer being created at that particular method call and never being released. Iam stuck in middle and have no clue what so ever.
Well, if what you are saying is true, specifically that the Mercury
Diagnostics tool claims that line is creating StringBuffers and never
allowing them to be garbage collected, then tell your boss that I say
the tool is unreliable and remind him that the tool is an aid to help
you but in the end it's up to you to apply your intelligence. (Not
that your boss has any reason to put any weight in what some random
Internet person has to say. :-)
If the tool is just identifying potentially wasted object creating
then yes, it's correct and other than the if
(logger.isSomeLevelEnabled()) idiom there isn't much you can do.
My personal opinion is unless you have gobs of spare time, don't worry
about this type of issue as it's really a small problem compared to
the performance characteristics of any meaningful application I've
worked on.
My experience is profilers produce a lot of noise and you should
consider its output a list of potential places to improve your code
but only handful of those places will have a meaningful effect if you
improve them.
> Our company is in process of evaluating Mercury Diagnosis tool and they really want us to go by the tool reports and make the changes . Iam stuck at this place and not sure what change to make.
The code you describe is so common and so simple that it would have
been identified long ago by many people had there been a real problem
there.
A good rule of thumb is If your code works well enough, then don't
change it if you don't have to because the change may break something.
> Sandy McArthur <sa...@apache.org> wrote:
> Naveen,
>
> That sample code will result in a String being passed to debug or
> info. The StringBuffer used internally by the compiler will be
> available for garbage collection after the StringBuffer is converted
> to a String and before the resulting String is passed as a parameter.
>
> There isn't a memory leak there as much as maybe wasted work done in
> object creation to create the method parameter. Using the if
> (logger.isDebugEnabled()) idiom Oliver suggested will save that work.
>
> I'm not familar with Mercury but if it really reports a leak there
> then it's probably false positive.
>
> On 6/7/06, Naveen wrote:
> > Hello all,
> >
> > Iam not sure if there is really amemory leak in Log4jLogger. We use Mercury diagnosis tool to find the memory leak and the reports show all the string buffers being held up at
> >
> > 1. org.apache.log4j.Logger.debug
> > 2. org.apache.log4j.Logger.info
> >
> > this is one of the call we make
> >
> > logger.debug(connectionID + "-" + message);
> >
> > logger is an instance of Log4j.Logger and connectionID,message are strings
> >
> > i know appending strings will internally create StrinBuffers but our memory reports show string buffers are never cleared which are areated during that call.
> >
> > any help is highly appreciated.
> >
> > Thanks,
> > Naveen.
> >
> >
> >
> >
> >
> >
> > Naveen
> >
> > It only takes a moment to be kind, but the results can be everlasting.!!
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
>
> Naveen
>
> It only takes a moment to be kind, but the results can be everlasting.!!
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Log4j String buffer memory Leak.
Posted by Naveen <na...@yahoo.com>.
Thanks a lot sandy and Oliver ..
but the issue remains...Mercury Diagnosis tools reports lot of Sting Buffer being created at that particular method call and never being released. Iam stuck in middle and have no clue what so ever.
Our company is in process of evaluating Mercury Diagnosis tool and they really want us to go by the tool reports and make the changes . Iam stuck at this place and not sure what change to make.
Sandy McArthur <sa...@apache.org> wrote:
Naveen,
That sample code will result in a String being passed to debug or
info. The StringBuffer used internally by the compiler will be
available for garbage collection after the StringBuffer is converted
to a String and before the resulting String is passed as a parameter.
There isn't a memory leak there as much as maybe wasted work done in
object creation to create the method parameter. Using the if
(logger.isDebugEnabled()) idiom Oliver suggested will save that work.
I'm not familar with Mercury but if it really reports a leak there
then it's probably false positive.
On 6/7/06, Naveen wrote:
> Hello all,
>
> Iam not sure if there is really amemory leak in Log4jLogger. We use Mercury diagnosis tool to find the memory leak and the reports show all the string buffers being held up at
>
> 1. org.apache.log4j.Logger.debug
> 2. org.apache.log4j.Logger.info
>
> this is one of the call we make
>
> logger.debug(connectionID + "-" + message);
>
> logger is an instance of Log4j.Logger and connectionID,message are strings
>
> i know appending strings will internally create StrinBuffers but our memory reports show string buffers are never cleared which are areated during that call.
>
> any help is highly appreciated.
>
> Thanks,
> Naveen.
>
>
>
>
>
>
> Naveen
>
> It only takes a moment to be kind, but the results can be everlasting.!!
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Naveen
It only takes a moment to be kind, but the results can be everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Log4j String buffer memory Leak.
Posted by Sandy McArthur <sa...@apache.org>.
Naveen,
That sample code will result in a String being passed to debug or
info. The StringBuffer used internally by the compiler will be
available for garbage collection after the StringBuffer is converted
to a String and before the resulting String is passed as a parameter.
There isn't a memory leak there as much as maybe wasted work done in
object creation to create the method parameter. Using the if
(logger.isDebugEnabled()) idiom Oliver suggested will save that work.
I'm not familar with Mercury but if it really reports a leak there
then it's probably false positive.
On 6/7/06, Naveen <na...@yahoo.com> wrote:
> Hello all,
>
> Iam not sure if there is really amemory leak in Log4jLogger. We use Mercury diagnosis tool to find the memory leak and the reports show all the string buffers being held up at
>
> 1. org.apache.log4j.Logger.debug
> 2. org.apache.log4j.Logger.info
>
> this is one of the call we make
>
> logger.debug(connectionID + "-" + message);
>
> logger is an instance of Log4j.Logger and connectionID,message are strings
>
> i know appending strings will internally create StrinBuffers but our memory reports show string buffers are never cleared which are areated during that call.
>
> any help is highly appreciated.
>
> Thanks,
> Naveen.
>
>
>
>
>
>
> Naveen
>
> It only takes a moment to be kind, but the results can be everlasting.!!
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE : RE : Log4j String buffer memory Leak.
Posted by Olivier Lamy <ol...@accor.com>.
IMHO,
When you do logger.debug(connectionID + "-" + message);
The string concatenation is evaluated before the call to the logger.
You will find some litterature to this on google.
HTH
--
Olivier
-----Message d'origine-----
De : Naveen [mailto:naween18@yahoo.com]
Envoyé : mercredi 7 juin 2006 18:03
À : Jakarta Commons Users List
Objet : Re: RE : Log4j String buffer memory Leak.
yes i use the first one..but will that cause memory leak if my logging
level is turned to INFO
Thanks,
Naveen.
Olivier Lamy <ol...@accor.com> wrote:
Simple question
You made
logger.debug(connectionID + "-" + message);
Or
If (logger.isDebugEnabled())
{
logger.debug(connectionID + "-" + message);
}
If using first, you create some String instance for nothing.
--
Olivier
-----Message d'origine-----
De : Naveen [mailto:naween18@yahoo.com]
Envoyé : mercredi 7 juin 2006 16:45
À : commons-user@jakarta.apache.org
Objet : Log4j String buffer memory Leak.
Hello all,
Iam not sure if there is really amemory leak in Log4jLogger. We use
Mercury diagnosis tool to find the memory leak and the reports show all
the string buffers being held up at
1. org.apache.log4j.Logger.debug
2. org.apache.log4j.Logger.info
this is one of the call we make
logger.debug(connectionID + "-" + message);
logger is an instance of Log4j.Logger and connectionID,message are
strings
i know appending strings will internally create StrinBuffers but our
memory reports show string buffers are never cleared which are areated
during that call.
any help is highly appreciated.
Thanks,
Naveen.
Naveen
It only takes a moment to be kind, but the results can be everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
This e-mail, any attachments and the information contained therein
("this message") are confidential and intended solely for the use of the
addressee(s). If you have received this message in error please send it
back to the sender and delete it. Unauthorized publication, use,
dissemination or disclosure of this message, either in whole or in part
is strictly prohibited.
------------------------------------------------------------------------
--------------------------------------
Ce message électronique et tous les fichiers joints ainsi que les
informations contenues dans ce message ( ci après "le message" ), sont
confidentiels et destinés exclusivement à l'usage de la personne à
laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion,
publication, totale ou partielle ou divulgation sous quelque forme que
se soit non expressément autorisées de ce message, sont interdites.
------------------------------------------------------------------------
-------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Naveen
It only takes a moment to be kind, but the results can be
everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: RE : Log4j String buffer memory Leak.
Posted by Naveen <na...@yahoo.com>.
yes i use the first one..but will that cause memory leak if my logging level is turned to INFO
Thanks,
Naveen.
Olivier Lamy <ol...@accor.com> wrote:
Simple question
You made
logger.debug(connectionID + "-" + message);
Or
If (logger.isDebugEnabled())
{
logger.debug(connectionID + "-" + message);
}
If using first, you create some String instance for nothing.
--
Olivier
-----Message d'origine-----
De : Naveen [mailto:naween18@yahoo.com]
Envoyé : mercredi 7 juin 2006 16:45
À : commons-user@jakarta.apache.org
Objet : Log4j String buffer memory Leak.
Hello all,
Iam not sure if there is really amemory leak in Log4jLogger. We use
Mercury diagnosis tool to find the memory leak and the reports show all
the string buffers being held up at
1. org.apache.log4j.Logger.debug
2. org.apache.log4j.Logger.info
this is one of the call we make
logger.debug(connectionID + "-" + message);
logger is an instance of Log4j.Logger and connectionID,message are
strings
i know appending strings will internally create StrinBuffers but our
memory reports show string buffers are never cleared which are areated
during that call.
any help is highly appreciated.
Thanks,
Naveen.
Naveen
It only takes a moment to be kind, but the results can be
everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
This e-mail, any attachments and the information contained therein ("this message") are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited.
--------------------------------------------------------------------------------------------------------------
Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après "le message" ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites.
-------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Naveen
It only takes a moment to be kind, but the results can be everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE : Log4j String buffer memory Leak.
Posted by Olivier Lamy <ol...@accor.com>.
Simple question
You made
logger.debug(connectionID + "-" + message);
Or
If (logger.isDebugEnabled())
{
logger.debug(connectionID + "-" + message);
}
If using first, you create some String instance for nothing.
--
Olivier
-----Message d'origine-----
De : Naveen [mailto:naween18@yahoo.com]
Envoyé : mercredi 7 juin 2006 16:45
À : commons-user@jakarta.apache.org
Objet : Log4j String buffer memory Leak.
Hello all,
Iam not sure if there is really amemory leak in Log4jLogger. We use
Mercury diagnosis tool to find the memory leak and the reports show all
the string buffers being held up at
1. org.apache.log4j.Logger.debug
2. org.apache.log4j.Logger.info
this is one of the call we make
logger.debug(connectionID + "-" + message);
logger is an instance of Log4j.Logger and connectionID,message are
strings
i know appending strings will internally create StrinBuffers but our
memory reports show string buffers are never cleared which are areated
during that call.
any help is highly appreciated.
Thanks,
Naveen.
Naveen
It only takes a moment to be kind, but the results can be
everlasting.!!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
This e-mail, any attachments and the information contained therein ("this message") are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited.
--------------------------------------------------------------------------------------------------------------
Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après "le message" ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites.
-------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org