On 18/10/2010 18:19, Martin O'Shea wrote:
> 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();
Why create a new factory and object each time, rather than when the
owning object is created - in the constructor?
Why use a controller object? It would be simpler to just create it all
in the ServletContextListener, wouldn't it?
p
> 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
>
> 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
---------------------------------------------------------------------
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
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
