[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CmdSchedule.pl specs
Well how long should it wait? Some scripts will take a second, others
maybe 10 minutes. The advantage of the perl wrapper for this is that the
perl script can keep track of what is in la la land in the DB and then do
garbage collection at regular intervals. You'll need to add another field
though- timeout.
So, yes you can, but it's more complicated. You need to code two threads-
one that waits for the return value, and one that watches the clock.
Never done that before so it won't make release 1.
On Mon, 28 Feb 2000, Jason Pincin wrote:
> > I don't think you need to worry about the Perl scripts hanging around
> > causing the system to crash. Perl doesn't have that much overhead. Of
> > course this means that all scripts need to return CORRECT error codes.
> > >= 0 is OK. < 0 is failure.
>
> OK, but what if a script it's calling goes off into lala land? Can
> Perl time out on waiting for the return code?
>
>
> >
> > On Sun, 27 Feb 2000, Jason Pincin wrote:
> >
> > > This email is directed mainly at Aaron, but others are encouraged to
> > > give it a gander.
> > >
> > > Regarding CmdSchedule.pl:
> > >
> > > This will be the LKB's scheduler. All scheduled events will flow
> > > through this. This provides us an easy way to offload anything that
> > > doesn't need to happen immediatly to create a more responsive site for
> > > users, as well as provide us, the developers, a unified way to schedule
> > > activities. The moderation system will be making immediate use of this
> > > system, and php functions will be developed to make it easy for php
> > > developers to utilize the system for objects.
> > >
> > > Now, onto the details (for Aaron's sake as he'll be coding this):
> > >
> > > The perl script(s) will execute via cron every minute. Upon execution
> > > the script will query the CmdSchedule table to look for any commands to
> > > be executed during that minute. If any commands meet that criteria,
> > > the perl script will spawn those events, update the table accordingly,
> > > and exit.
> > >
> > > The fields, Hour, Minute, WeekDay, MonthDay, and Month, must match in
> > > typical cron fassion. In addition to this, Status must be "Waiting" or
> > > "PendingRetry". RepeatCount must be greater than 0 or less than 0 OR
> > > equal to 0 with a status of "PendingRetry".
> > >
> > > If these criteria are met, the command in the ExternalCmds table that
> > > matches the CommandID in the CmdSchedule table is spawned with the
> > > Target Objects field passed as parameters. The record in CmdSchedule
> > > is then updated to reflect this. This update entails the following:
> > >
> > > RepeatCount is decremented by 1 unless it is -1 which means no
> > > repeat limit, or if it's 0 already. Status should be set to "Running".
> > > LastRun should be set to the time of the execution. Attempts should be
> > > incremented by 1.
> > >
> > > If the script fails for any reason, the status should be set to
> > > PendingRetry. This should probably be done within the script so that
> > > the perl script doesn't have to hang around. Thoughts?
> > >
> > > If the PerlScript runs and finds any commands in a state of "Waiting"
> > > with a repeatCount of 0, those records should be removed.
> > >
> > > If it runs, and finds any records in a state of "PendingRetry" with an
> > > Attempts of 3 or more, the status should be set to "Failed" and an
> > > email should be generated to the NotificationAddresses.
> > >
> > > It should probably also be up to the scripts themselves to update
> > > Status to "Waiting" when they are finished executing. Again, thoughts
> > > welcome, but I don't think the Perl script should hang around. Any
> > > script issues would cause the Perl script to hang around possibly
> > > causing cron continuing to spawn until the system pukes. If you have
> > > better ideas let me know, but I don't have a problem with making the
> > > scripts and the scheduler working together for now.
> > >
> > > I think thats enough detail on how it should work. I only need support
> > > for *, -, and "," operators in the time fields for starters.
> > >
> > > I probably didn't cover everything in the best order here... so if you
> > > can't make order or sense out of it, hit me with your Q's.
> > >
> > > Thanks!
> > >
> > >
> > >
> > > --
> > > Jason Pincin
> > > Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
> > > http://vodka.linuxkb.org/~chardros/
> > >
> >
> > --
> > Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
> > Linux Knowledge Base Organization http://www.linuxkb.org/
> > Because world domination requires quality open documentation.
> > aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
> > The difference between `Unstable' and `Usable' is only two characters: NT
>
> --
> Jason Pincin
> Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
> http://vodka.linuxkb.org/~chardros/
>
--
Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization http://www.linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
The difference between `Unstable' and `Usable' is only two characters: NT