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 <prab...@icloud.com> 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 >> <webobjects-dev@lists.apple.com> 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 <sam...@samkar.com> 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 <jtay...@oeinc.com> 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 <sam...@samkar.com> 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 <jtay...@oeinc.com> 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 (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/prabier%40icloud.com >> >> This email sent to prab...@icloud.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
