Re: Quartz Scheduler -- Clustering
Re: Quartz Scheduler -- Clustering
- Subject: Re: Quartz Scheduler -- Clustering
- From: Jesse Tayler via Webobjects-dev <email@hidden>
- Date: Sun, 16 Feb 2025 13:23:18 -0500
Thanks, I did see those, I’m not certain how much I misunderstood but I think
I’ve got the hang of it now perhaps.
I think one trouble is I’m on an unfortunately old version right now, but also
I was under the impression that the Wonder framework somehow used the Database
as a central authority on grabbing tasks so that only one instance would handle.
I’d still rather see that than a signal instance being in charge but I won’t
fuss if that’s what is to be done.
So, right now? I plan to implement something so that only one instance is in
change of polling and I guess I’ll send a flag from JavaMonitor so tell that
instance to turn on.
I did implement Samuel’s changes in initialization constructors and now find
things to be far more normal - thank you Samuel
> On Feb 16, 2025, at 10:16 AM, Philippe Rabier <email@hidden> wrote:
>
> Hi Jesse,
>
> I think you should spend some time reading the documentation.
>
> Here are some pointers:
> - https://www.slideshare.net/slideshow/framework-principal/23337152
> - https://www.slideshare.net/slideshow/co-scheduler/9169056
> - https://www.slideshare.net/slideshow/co-scheduler-indepth/13551537
>
> The framework principal pattern is underused IMHO. No need to initialize
> anything in the application class.
>
> The two other presentations can help. COScheduler was the previous name of
> ERQuarzScheduler.
>
> I’m a bit surprised you want/need a cluster but if so, it won’t work because
> it hasn’t been designed for this purpose.
>
> I haven’t used WO stuff since 2015 but more tha 12 years ago, we had a
> dedicated application that handled hundreds of jobs per day.
>
> If it can help…
>
> Philippe
>
>> On 16 Feb 2025, at 15:27, Jesse Tayler via Webobjects-dev
>> <email@hidden> wrote:
>>
>>
>> I was somehow certain that only one instance could pick up a job in the
>> first place! You basically run a single instance for the job queuing and
>> that works okay?
>>
>> I notice you have a separated didFinish and finishInit call set there far
>> later than mine.
>>
>> I figure I’m loading before the properties are available. Perhaps a property
>> flag triggers something that causes my server issue.
>>
>> I see a shared instance - okay. And yes, mine gets jobs and those send email
>> okay right now…
>>
>> My framework principal could not be more simple - it sets up in the static
>> and provides EO support but it does not have a finishInit Override…I’m not
>> sure about the shared instance…I don’t seem to be setting that right now...
>>
>> In the app main() I set this class up as soon as possible, the other places
>> to initialize further down the line, seems to crap out on my server for
>> reasons I cannot figure.
>>
>> public static void main(String[] argv) {
>> principal = new TruAnonSchedulerServiceFrameworkPrincipal();
>>
>> I believe I keep the principal around to keep it in memory, but I’d suppose
>> this would be done if I had set the shared instance like you did.
>>
>> I’d like to clean this up, but I’m worried that you use only one instance!
>>
>> I thought this EOF would provide a lock so the cluster would handle the
>> queue whenever an instance got a chance — but no duplicate emails.
>>
>> Is this not the case? This framework is really for the cron? Not as a
>> singular job queue?
>>
>>
>>
>>> On Feb 16, 2025, at 9:07 AM, Samuel Pelletier <email@hidden> wrote:
>>>
>>> I do not have startup problems and use these properties to disable job by
>>> default and only start then on the designed instance:
>>>
>>> er.quartzscheduler.schedulerServiceToLaunch=true
>>> er.quartzscheduler.triggersAutomaticallyPaused=true
>>>
>>> On the instance that should run the tasks I set
>>> er.quartzscheduler.triggersAutomaticallyPaused=false
>>>
>>> This cause Quartz to load but no task are started, The is a component in
>>> the frameworks to see the current scheduling state and individual task
>>> schedule at runtime you can put in your app: <wo:ERQSJobInformations/>.
>>>
>>> Havi you implemented a ERQSSchedulerServiceFrameworkPrincipal derived class
>>> as explained in the readme file and call the initializer as described in
>>> the readme ?
>>>
>>> * Create your own framework principal and implement the methods: *
>>> *
>>> • getListOfJobDescription that is called by the job supervisor to know
>>> the list of jobs that must be handled by the Quartz scheduler. *
>>> • newEditingContext() called when a job needs a new ec *
>>> • newEditingContext(final EOObjectStore parent) called when a job needs a
>>> new ec *
>>> * Read more {@link
>>> er.quartzscheduler.util.ERQSSchedulerServiceFrameworkPrincipal#newEditingContext()}
>>> * *
>>>
>>> Here is my code for that. ScheduledJob is my EOEntity use to store task
>>> schedule.
>>>
>>> In Application.java...
>>>
>>> @Override
>>> public void didFinishLaunching() {
>>> super.didFinishLaunching();
>>> new SchedulerPrincipal().finishInitialization();
>>> }
>>>
>>> public class SchedulerPrincipal extends
>>> ERQSSchedulerServiceFrameworkPrincipal {
>>> EOEditingContext ec = null;
>>> NSArray<? extends ERQSJobDescription> jobs = null;
>>> static
>>> {
>>> setUpFrameworkPrincipalClass(SchedulerPrincipal.class);
>>> }
>>> @Override
>>> public void finishInitialization() {
>>> super.finishInitialization();
>>> ERQSSchedulerServiceFrameworkPrincipal.setSharedInstance(this);
>>> }
>>> @Override
>>> protected void initialize() {
>>> super.initialize();
>>> }
>>> @Override
>>> public NSArray<? extends ERQSJobDescription>
>>> getListOfJobDescription(EOEditingContext ec) {
>>> this.ec = ec;
>>> jobs = ScheduledJob.fetchAllScheduledJobs(ec);
>>> return jobs;
>>> }
>>>
>>> @Override
>>> public EOEditingContext newEditingContext() {
>>> return ERXEC.newEditingContext(); //?
>>> }
>>>
>>> @Override
>>> public EOEditingContext newEditingContext(EOObjectStore parent) {
>>> return ERXEC.newEditingContext(parent); //?
>>> }
>>>
>>> }
>>>
>>> Samuel
>>>
>>>
>>>
>>>> Le 15 févr. 2025 à 23:55, Jesse Tayler <email@hidden> a écrit :
>>>>
>>>> Thanks, I seem to have found that by initializing Quartz in my Applicaiton
>>>> main(), very early even — I have it working but I GET TWO EMAILS! I have
>>>> two instances and they both send the same notifications. Grrr...
>>>>
>>>> I was sure I read code that was locking the Database and I figured a date
>>>> or something was being used to prevent that in a cluster?
>>>>
>>>> I also notice that I do NOT seem to have control over properties? Such as
>>>> turning it on/off
>>>>
>>>> er.quartzscheduler.schedulerServiceToLaunch=true
>>>>
>>>> Vs false seems to have no effect.
>>>>
>>>> I have to spark Quartz up by hand, in my main() and that’s odd —
>>>>
>>>> Something is afoot!
>>>>
>>>>
>>>>
>>>>> On Feb 15, 2025, at 11:43 PM, Samuel Pelletier <email@hidden> wrote:
>>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> I would try to set the main log level to debug and look at the entries...
>>>>> There is maybe some hints there.
>>>>>
>>>>> In WOApplication, the code will print uncatched exception to stderr, make
>>>>> sure you capture this output.
>>>>> /* 556 */ NSLog.err.appendln((Object)("A fatal exception
>>>>> occurred: " + throwable.getMessage()));
>>>>>
>>>>> It appears like this in debug console when I trigger an
>>>>> IllegalAccessError in a framework didFinishInitialization() handler.
>>>>> févr. 15 23:27:43 AppName[2325] WARN NSLog - A fatal exception
>>>>> occurred: java.lang.IllegalAccessError
>>>>> Exception stock trace printed here
>>>>>
>>>>> I have no idea where these 2 lines come from:
>>>>>> Terminating Session Instance
>>>>>> New Session Instance
>>>>>
>>>>> Hope this can help.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Samuel
>>>>>
>>>>>
>>>>>> Le 14 févr. 2025 à 18:00, Jesse Tayler <email@hidden> a écrit :
>>>>>>
>>>>>> I have the scheduler working but somehow on production, (which is in a
>>>>>> container) it simply craps out seemingly right around the time Quartz
>>>>>> rolls in.
>>>>>>
>>>>>> So the app starts up and connects to RDBMS as normal.
>>>>>>
>>>>>> A few seconds in, around the time I would expect Quartz to load up and
>>>>>> query- it dies.
>>>>>>
>>>>>> But there’s no error, it seems like the app was asked to shut down?
>>>>>>
>>>>>> A watchdog?
>>>>>>
>>>>>> Too much RAM?
>>>>>>
>>>>>> Feb 14 17:10:07 TruAnon[2002] DEBUG NSLog - 0 row(s) processed
>>>>>> Feb 14 17:10:07 TruAnon[2002] DEBUG NSLog - === Commit Internal
>>>>>> Transaction
>>>>>> Terminating Session Instance
>>>>>> New Session Instance
>>>>>> APPLICATION SHUTDOWN SEQUENCE COMPLETE
>>>>>>
>>>>>> Boom
>>>>>>
>>>>>> It’s dead and gone.
>>>>>>
>>>>>> Any idea how a WO app can gracefully die like that without any error?
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden