[ot] Quartz ?
Brent Putman
putmanb at georgetown.edu
Wed Mar 11 17:19:48 EDT 2015
On 3/11/15 4:15 PM, Tom Zeller wrote:
> On Wed, Mar 11, 2015 at 2:14 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>> 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.
> 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.
Yeah, I used Spring's support for my jobs, so everything wired in
Spring XML.
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.
>
> 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,
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).
> and would be useful given the issues with Timers and Tomcat's
> complaining about them.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150311/c39c76d6/attachment.html
More information about the dev
mailing list