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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
