OK. So the error is happening as the application is closed, not as it started. My mistake. But Tomcat restarts occur frequently as I have NetBeans's Deploy on Save set. This seems to restart the server with the current objects.
But what I don't understand is why the ServletContextListener which handles Quartz jobs should be going wrong? It is set to start and stop Quartz at contextInitialized and contextDestroyed times where the former creates an instance of a SchedulerController class which submits the two jobs. This problem never appeared to happen under NetBeans 6.9 with an earlier version of Tomcat which I was using recently. And I wonder if this may have anything to do with the Tomcat out of memory messages I've been receiving? Do I need to increase the memory allocated to the JVM for Tomcat at all? -----Original Message----- From: Pid * [mailto:p...@pidster.com] Sent: 16 Oct 2010 15 06 To: Tomcat Users List Subject: Re: Tomcat memory leak error launching web app in NetBeans 6.9.1 On 16 Oct 2010, at 12:45, Martin O'Shea <app...@dsl.pipex.com> wrote: > Hello > > I wonder if anyone can help here? I am developing a web application written > in Java servlets and JSPs which uses Quartz 1.6.1 to submit two jobs when > Apache Tomcat 6.0.26 is started and hourly after that. > > But what I'm finding is that a message is issued several times as the server > is started in NetBeans 6.9.1. The message is: > > 16-Oct-2010 12:20:18 org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: A web application appears to have started a thread named > [DefaultQuartzScheduler_Worker-1] but has failed to stop it. This is very > likely to create a memory leak. Yes. So, umm, your webapp uses quartz - which is starting threads and not stopping them. > Has anyone any idea? It seems to be causing Tomcat to stop every so often > requiring a PC reboot. And I've found very little about this so far. The error message is issued by Tomcat when an app is stopped and it finds resources that haven't been properly terminated. The message itself is doesn't cause a leak, the source of the problem might - as the message itself states. > I don't know if it is a problem with Tomcat or Quartz so any help is welcome Quartz, or the way you've configured it. p > > > Thanks > > Martin O'Shea. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
