Hi, 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.
Logs are not fabricated, yeah i took only the portion when problem started. and the JVM crash dump. 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. BR, Shahnaz Ali. On Thu, Apr 8, 2010 at 1:47 PM, Michael Erskine <mse...@googlemail.com>wrote: > On 8 April 2010 07:47, Shahnaz Ali <shaan20...@gmail.com> wrote: > > No, there was no any hot deployment. > > But the evidence points to a change of class so something equivalent > to a redeployment must have happened. Something caused a deployed > class to be reloaded and that operation failed due to a class > incompatibility. That is what happened. Unless the logs are somehow > fabricated :) > > The cause of the crash however could be anything! Have a try at > repeating it by dropping newer Wars and Jars. Upgrade your Java > runtime to apply all the officially available fixes. Quit running > Tomcat as root :) > > Regards, > Michael Erskine. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
