Thanks Mark. Your test seems to bear out the issue I'm having.
For information: I have my own ServletContextListener which has a
contextDestroyed method as follows:
@Override
public void contextDestroyed(ServletContextEvent contextEvent) {
context = contextEvent.getServletContext();
Scheduler_Controller sc = new Scheduler_Controller();
// Is scheduler stopped?
try {
if (sc.isSchedulerStopped()) {
System.out.println("The scheduler is already stopped.");
}
else {
try {
sc.stopScheduler();
System.out.println("The scheduler has been stopped.");
}
catch(Exception ex) {
logger.error("Error stopping scheduler\n" + ex);
}
}
}
catch(Exception ex) {
logger.error("Error stopping scheduler\n", ex);
}
}
Methods isSchedulerStopped and stopScheduler follow:
public boolean isSchedulerStopped() throws Exception {
SchedulerFactory sf = new StdSchedulerFactory();
Scheduler scheduler = sf.getScheduler();
scheduler = StdSchedulerFactory.getDefaultScheduler();
if (scheduler.isShutdown()) {
return true;
}
else {
return false;
}
}
public void stopScheduler() throws Exception {
SchedulerFactory sf = new StdSchedulerFactory();
Scheduler scheduler = sf.getScheduler();
scheduler = StdSchedulerFactory.getDefaultScheduler();
Scheduler_Job sj = null;
// First scheduled job.
try {
sj = Scheduler_Job_DB.get(1);
scheduler.unscheduleJob(sj.getJobName(),
scheduler.DEFAULT_GROUP);
System.out.println("Job " + sj.getJobName() + " unsubmitted.");
}
catch(Exception ex){
logger.error("Error unsubmitting job " + sj.getJobName() + "\n",
ex);
}
// Second scheduled job.
try {
sj = Scheduler_Job_DB.get(2);
scheduler.unscheduleJob(sj.getJobName(),
scheduler.DEFAULT_GROUP);
System.out.println("Job " + sj.getJobName() + " unsubmitted.");
}
catch(Exception ex){
logger.error("Error unsubmitting job " + sj.getJobName() + "\n",
ex);
}
scheduler.shutdown(true);
if (scheduler.isShutdown()) {
System.out.println("Scheduler stopped");
}
}
So I think that according to these, the scheduler should end 'gracefully' by
unsubmitting the jobs and by using scheduler.shutdown(true);.
If I'm wrong, please let me know.
-----Original Message-----
From: Mark Eggers [mailto:its_toas...@yahoo.com]
Sent: 18 Oct 2010 18 06
To: Tomcat Users List
Subject: Re: Tomcat memory leak error launching web app in NetBeans 6.9.1
I saw a mention of this on the Quartz forums. People there seem to think
it's a
race condition between Quartz's scheduler shutdown and Tomcat's thread
memory
leak reporting.
I wrote a quick Quartz scheduler (1.8.3) application. It does the following:
1. Uses the supplied listener to put a scheduler factory in the servlet
context
(org.quartz.ee.servlet.QuartzInitializerListener)
2. Uses another listener to add a job that writes to a log file every 5
minutes
3. Uses the provided listener
(org.quartz.ee.servlet.QuartzInitializerListener)
to shut down
all schedulers
The supplied listener is configured via parameters to start the scheduler on
startup, and shut down the scheduler on application termination.
When I watch this using visualvm (1.3.1) on Tomcat 6.0.18 and 6.0.29, I see
the
four threads that are started by Quartz vanish when the application is
undeployed. Tomcat reports the SEVERE error for some of these threads in
catalina.out. I ran the test twice and I think that Tomcat reported
different
threads on each run (didn't save the log files). I also didn't look for any
stray classes left after the application was undeployed.
The supplied listener can be configured to not start or shut down the
scheduler.
Starting and shutting down the scheduler can then be managed by the second
listener (that adds the job). I've not tried this yet.
Finally, there are two ways to shut down the scheduler. The default
(graceful)
way waits for any pending jobs to complete. Calling shutdown(false)
immediately
terminates the scheduler. This doesn't seem to be configurable using the
supplied listener, so the scheduler would have to be managed by the second
listener.
Environment:
OS: Fedora 13 2.6.34.7-56.fc13.i686
Java: Oracle/Sun Java JRE/JDK 1.6.0_22
IDE: NetBeans 6.9.1 / Maven 2.2.1
Tomcat: 6.0.29
6.0.18
Quartz: 1.8.3
Monitor: VisualVM 1.3.1 (https://visualvm.dev.java.net/)
If I have some time today, I'll try some variations.
. . . . just my two cents.
/mde/
----- Original Message ----
From: Martin O'Shea <app...@dsl.pipex.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Mon, October 18, 2010 5:52:08 AM
Subject: RE: Tomcat memory leak error launching web app in NetBeans 6.9.1
You're probably correct and assuming this is to do with Quartz which it
seems to
be, are you aware of any similar cases or remedies?
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 18 Oct 2010 13 49
To: Tomcat Users List
Subject: Re: Tomcat memory leak error launching web app in NetBeans 6.9.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin,
On 10/16/2010 11:11 AM, Martin O'Shea wrote:
> Definitely seems to be when the web application in question is terminated,
>rather than Tomcat itself. And all indications are the listener that
handles the
>scheduler.
>
> And I've tried another similar application which gives messages of the
same
>kind.
>
> And yet both apps have worked under other environments.
Note that the leak detection has been added and improved in recent
Tomcat versions. It's possible that this problem has always been there,
you're just never been notified about it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky8QkkACgkQ9CaO5/Lv0PAwNACfVwsejeJhSe3CajEWqQraiXTf
amwAoI8Kl+4V07E7Tv4Axn8ASiJRq8Pm
=9dxR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
