logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shahnaz Ali <shaan20...@gmail.com>
Subject Re: JVM crash with Log4J.
Date Thu, 08 Apr 2010 14:16:42 GMT
We have test server but how we will create actual load on that. Recreating
this problem is a challenge. After restarting, its working fine from last
around 3 weeks. One server receives 80,000 call requests in a day on
average. Since then no issue.... It is basically serving VXML for telephony

We can upgrade tomcat, Java.... but who will give guarantee this problem
wont occur again. I am going clueless. :o

And dont tell me please, forget this crash then. I can forget, customer
wont. :P

Any suggestion?

On Thu, Apr 8, 2010 at 3:09 PM, Michael Erskine <msemtd@googlemail.com>wrote:

> On 8 April 2010 10:27, Shahnaz Ali <shaan20sep@gmail.com> wrote:
> > Its not possible to do these kind of experiments in running production
> > server. But i am sure there is nothing happened like redeploying new war,
> > jar or any kind of change. Server was untouched for last several hours.
> Don't you have an identical test/backup server running your production
> code? :o

> > The reason of crash even could be out of Log4J, but i m here to discuss,
> why
> > logs are pointing to only Log4J. And more over all the errors it is
> pointing
> > should not even work after tomcat restart. Infact everything is working
> fine
> > after OS restart without any single change.
> Log4j logs it's problems so when underlying problems occur, they get
> logged! If your platform (JVM, application server, host OS) is
> unstable (or suspect it is), set up some test conditions and try to
> recreate the problem. I can't suggest anything more than that without
> doing your job for you :)

> Regards,
> Michael Erskine.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message