I was able to achieve similar with Deltaspike's own Deactivable. It does
work, i.e. I can set:
org.apache.deltaspike.core.spi.activation.ClassDeactivator=org.apache.deltaspike.core.impl.activation.DefaultClassDeactivator
deactivate.org.apache.deltaspike.scheduler.impl.SchedulerExtension=true
in my configs, and Scheduler stays off. But - as mentioned - I need this
to be evaluated on system startup, not at Config level. So I tried
implementing my own SchedulerExtension like:
public class MySchedulerExtension extends SchedulerExtension {
@Override
protected void init(@Observes BeforeBeanDiscovery beforeBeanDiscovery) {
if (isSchedulerNode())
super.init(beforeBeanDiscovery);
}
}
I can register it via SPI and from the logs I see it is indeed
initialized, while SchedulerExtension is not. Victory, right? Not quite...
I am testing this with OpenWebbeans 2.0.6., and I face the problem, that
CDI now complains about ambiguous Bean for SchedulerExtension in
SchedulerProducer (which I can see where that comes from), but I am just
not able to exclude SchedulerProducer - I wouldn't even need it. I tried
various combinations of @Specialize, @Alternative and <scan><exclude
.../></scan>, but none of them seem to work. I guess the reason for it
is the CDI 1.0 beans.xml in scheduler-impl? Can anybody confirm? Would
it be possible to move higher - 1.1 at least for getting support for
<scan><exclude .../></scan>?
This leads me to the assumption, that scheduler-impl's
SchedulerExtension is just not extensible at the moment. Or did anybody
succeed in such an endeavor?
Since I do not want to patch the implementation, my next guess is to
implement a custom ConfigSource, which evaluates isSchedulerNode() and
sets deactivate.org.apache.deltaspike.scheduler.impl.SchedulerExtension
accordingly. Does that make sense?
Kind regards,
Juri
On 1/24/19 9:04 PM, Alex Roytman wrote:
in my case i need to be able to turn it on/off on demand and I only have
couple of daily tasks so for me it was good enough
If if you just need to do it on startup by node type you could bind it to a
property
@Scheduled(cronExpression = "{reindex.schedule}")
public class ReindexTask implements org.quartz.Job {
...
and that property could probably be a cron expression which never fire on
all of your nodes but the scheduler
not nice but the whole thing is rather static - admittedly i did not dig
very deep
On Thu, Jan 24, 2019 at 2:44 PM Juri Berlanda <[email protected]>
wrote:
Thanks for the quick reply. I thought about that, but I don't like this
solution, since it involves to much boilerplate for my taste. In
addition, I find it cumbersome having to add these 2 lines in every
single task. I also thought about having an abstract base class for this
purpose, but I'm not happy with the solution...
In short: I hoped for a cleaner solution.
On 1/24/19 7:03 PM, Alex Roytman wrote:
Let the scheduler run and execute your task but inside of the task
itself
check if you want to execute your logic or short circuit it to noop.
Since
you do not run it often should not be an overhead and it will let you
fail
over for any mode to execute it as long as you have a mechanism to lock
on
something and record execution result to avoid simultaneous execution or
double exexution
On Thu, Jan 24, 2019, 12:37 PM Juri Berlanda <[email protected]
wrote:
Hi,
I am currently trying to implement scheduled jobs using DeltaSpike's
Scheduler module, and I really like how little boilerplate I need for
getting it up and running.
Our application runs on multiple nodes, but the tasks are very
inexpensive, run only once a day, and I don't need failover - if they
fail once, and succeed the day after its totally fine. Therefore I'd
like to avoid setting up Quartz in clustered mode. But I still want the
Jobs to only run once. So my idea was to restrict the execution of the
jobs to a single scheduler node.
So my question is: Is it possible to somehow hook into the Scheduler
module to say something like:
if (isSchedulerNode())
startScheduler();
else
doNothing();
It would be perfect if said isSchedulerNode() could be evaluated on
system startup (e.g. acquire a distributed lock) and would not rely on
static values (e.g. config files, environment variables, etc.).
I can see how this is a bad idea in general (no load-balancing, no
failover) and I do have some ideas on how I would implement that. But
for these jobs I just don't care about any of this, so I'd like to avoid
having to set up a whole lot of infrastructure around my application
just to see this working.
Is there a possibility to achieve this without patching
deltaspike-scheduler-module-impl?
Kind regards,
Juri
