<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 3/11/15 4:15 PM, Tom Zeller wrote:<br>
</div>
<blockquote
cite="mid:CAMNmQDS3yFr=-UhT4b+tPJko8tUwkDkDUBptfO3uoh78hNxZ1g@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Mar 11, 2015 at 2:14 PM, Brent Putman <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm not Walter, but you may recall I mentioned awhile back that I have
used Quartz here at GU. Not a guru/expert, but pretty familiar. I
had brought up using Quartz as a possible replacement for our use of
Timer/TimerTasks for background tasks and so on.
</pre>
</blockquote>
<pre wrap="">
Similar experience here. We (Memphis) were hesitant to use Quartz at
first, hence my question to Walter. IIRC we used XML files to control
job scheduling, and it seemed so much better than cron or Timers.</pre>
</blockquote>
<br>
Yeah, I used Spring's support for my jobs, so everything wired in
Spring XML.<br>
<br>
We have another project which my colleague worked on, where
long-running jobs get scheduled dynamically at runtime. The
relevant code gets hold of the (single) Scheduler instance and
dynamically creates a Job and Trigger to run it. I'd imagine
something like our metadata providers would get handed the Scheduler
and would work that way, since they want to schedule their own next
refresh.<br>
<br>
<br>
<blockquote
cite="mid:CAMNmQDS3yFr=-UhT4b+tPJko8tUwkDkDUBptfO3uoh78hNxZ1g@mail.gmail.com"
type="cite">
<pre wrap="">
I don't think replacing Timers in v3 is on the roadmap, but maybe it's
something someone could work on as part of approaching the v3 code,</pre>
</blockquote>
<br>
No, and it would have to be v4+, since getting the Timers out of the
interfaces would I imagine be a breaking change, modulo our
discussions about changes in -impl modules as well as where the
affected code actually lives (some may actually be in -api modules).<br>
<br>
<br>
<blockquote
cite="mid:CAMNmQDS3yFr=-UhT4b+tPJko8tUwkDkDUBptfO3uoh78hNxZ1g@mail.gmail.com"
type="cite">
<pre wrap="">
and would be useful given the issues with Timers and Tomcat's
complaining about them.
</pre>
</blockquote>
<br>
Well, I had a similar issue with the Quartz Scheduler in that when
its shutdown() is called when the ApplicationContext is shutdown,
not all the worker threads were actually gone by the time the
servlet container tried to shutdown the servlet context, hence
spurious warnings in Tomcat about those threads. There were various
discussion about this on the interwebs, but I ended up doing the
simple thing and used a custom Spring SchedulerFactoryBean subclass
that overrides destroy() and puts in a 1 or 2 second delay, to give
the worker threads time to exit. Not pretty but seems to work ok.<br>
</body>
</html>