Fourth try, OpenWFEru and Rails
lee....@gmail.com
into the void. That's happened to me on another google group page --
has anyone else seen that?
Anyway, the scheduler is great. I ended up putting the instantiation
and scheduling into a .rb file required from environment.rb, so it
starts up when the application does.
However, that also makes it start up in script/console. I don't want
to have two schedulers' tasks stomping on each other when I run the
server and console at the same time. I could probably use a semaphore
stashed in memcached or the database or something. Does anyone have
other ideas?
Is there any way to stop a particular schedule_every task? Or should I
allocate a scheduler to it and just stop that when I need to?
I did this:
scheduler.schedule_at(Time.parse('18 July 2007 14:09:00')) { puts
"Running the AT job" }
which is very nice. However, it runs at the start of every application
launch, well past the time specified. I consider this a bug, since I'd
like to use it to perform a database action once a month without
having to worry about it repeating with every application restart.
Thanks!
Lee
John Mettraux
On 7/19/07, lee....@gmail.com <lee....@gmail.com> wrote:
>
> Anyway, the scheduler is great. I ended up putting the instantiation
> and scheduling into a .rb file required from environment.rb, so it
> starts up when the application does.
>
> However, that also makes it start up in script/console. I don't want
> to have two schedulers' tasks stomping on each other when I run the
> server and console at the same time. I could probably use a semaphore
> stashed in memcached or the database or something. Does anyone have
> other ideas?
Maybe something like
---8<---
unless defined? $scheduler
$scheduler = OpenWFE::Scheduler.new
$scheduler.start
#...
end
--->8---
> Is there any way to stop a particular schedule_every task? Or should I
> allocate a scheduler to it and just stop that when I need to?
The methods schedule(), schedule_at() and schedule_every() each
returns a 'jobid' when called.
You can do :
---8<---
jobid = $scheduler.schedule_every("10s") { puts "hello !" }
#... a bit later
$scheduler.unschedule(job_id)
--->8---
I will document that a bit more.
> I did this:
> scheduler.schedule_at(Time.parse('18 July 2007 14:09:00')) { puts
> "Running the AT job" }
> which is very nice. However, it runs at the start of every application
> launch, well past the time specified. I consider this a bug, since I'd
> like to use it to perform a database action once a month without
> having to worry about it repeating with every application restart.
It's true the schedule_at() will trigger task in the past immediately
and not schedule them.
But should we consider that a bug ? It's a bit weird to have absolute
dates in your program. Why don't you use a [cron] schedule() ?
---8<---
$scheduler.schedule("0 23 1 * *") { do_the_database_task() }
#
# will trigger this task on the 1st of each month at 23:00
--->8---
For more explanation on the cron configuration type "man 5 crontab" in
your favourite unix box or get there :
http://unixhelp.ed.ac.uk/CGI/man-cgi?crontab+5
Hope this helps, best regards,
--
John Mettraux -///- http://jmettraux.openwfe.org
lee....@gmail.com
> Maybe something like
>
> ---8<---
> unless defined? $scheduler
> $scheduler = OpenWFE::Scheduler.new
> $scheduler.start
> #...
> end
> --->8---
That wouldn't work between script/server and script/console, would it,
since those are basically two instantiations of the application?
$scheduler isn't shared across runs of the app.
> The methods schedule(), schedule_at() and schedule_every() each
> returns a 'jobid' when called.
>
> You can do :
>
> ---8<---
> jobid = $scheduler.schedule_every("10s") { puts "hello !" }
>
> #... a bit later
>
> $scheduler.unschedule(job_id)
> --->8---
I had noticed the job ID, and inspected the class, but didn't see the
unschedule method. Thanks for pointing it out.
> It's true the schedule_at() will trigger task in the past immediately
> and not schedule them.
>
> But should we consider that a bug ? It's a bit weird to have absolute
> dates in your program. Why don't you use a [cron] schedule() ?
Weird, yes. The reason I can't use cron-style scheduling is because I
want to schedule something (for example) for two days before the end
of the month. You can't do that with "every 28th of the month".
Could I convince you that running a schedule_at item from the past is
a bug? :-)
Thanks for all the help!
Lee
Nicolas H. Modrzyk
Hi,
> Could I convince you that running a schedule_at item from the past is
> a bug? :-)
>
I don't think this is a bug.
I've asked John to do this a while ago, because it was in my business
requirements to actually execute all the tasks scheduled with a past
date on waking up the scheduler.
In your case though, it looks like this feature is not needed at all,
so there should be a way to tell the scheduler whether to forget the
tasks with a past date or not.
What do you think ?
Nicolas,
John Mettraux
BTW, where are you based ? I'm in Yokohama, Japan.
On 7/19/07, lee....@gmail.com <lee....@gmail.com> wrote:
>
> On Jul 18, 8:04 pm, "John Mettraux" <jmettr...@openwfe.org> wrote:
> > Maybe something like
> >
> > ---8<---
> > unless defined? $scheduler
> > $scheduler = OpenWFE::Scheduler.new
> > $scheduler.start
> > #...
> > end
> > --->8---
>
> That wouldn't work between script/server and script/console, would it,
> since those are basically two instantiations of the application?
> $scheduler isn't shared across runs of the app.
You're right. What about a file semaphore (IIRC, as you suggested
before). Or simply something that notices that the console is being
triggered and not the application itself. $0 ?
---8<---
sonanda:~/openwfe-ruby mettraux$ irb
irb(main):001:0> puts $0
irb
=> nil
sonanda:~/openwfe-ruby mettraux$ ruby -e "puts $0"
-e:1: undefined local variable or method `bash' for main:Object (NameError)
--->8---
> I had noticed the job ID, and inspected the class, but didn't see the
> unschedule method. Thanks for pointing it out.
http://openwferu.rubyforge.org/rdoc/classes/OpenWFE/Scheduler.html
(double checking, yes it's documented).
> > It's true the schedule_at() will trigger task in the past immediately
> > and not schedule them.
> >
> > But should we consider that a bug ? It's a bit weird to have absolute
> > dates in your program. Why don't you use a [cron] schedule() ?
>
> Weird, yes. The reason I can't use cron-style scheduling is because I
> want to schedule something (for example) for two days before the end
> of the month. You can't do that with "every 28th of the month".
>
> Could I convince you that running a schedule_at item from the past is
> a bug? :-)
Well, I rely on this behaviour in some of my applications (and also
Nicolas). What about something like :
scheduler.schedule_at(past_moment, :discard_past => true) do
#whatever
end
When the parameter :discard_past is set to true, if the event is due
for the past, it would not be executed at all (and the call would
return null). :discard_jobs_in_the_past ?
Would that suit you ? There's maybe a better name for that param.
Wdyt ?
John Mettraux
On 7/19/07, John Mettraux <jmet...@openwfe.org> wrote:
>
> You're right. What about a file semaphore (IIRC, as you suggested
> before). Or simply something that notices that the console is being
> triggered and not the application itself. $0 ?
>
> ---8<---
> sonanda:~/openwfe-ruby mettraux$ irb
> irb(main):001:0> puts $0
> irb
> => nil
>
> sonanda:~/openwfe-ruby mettraux$ ruby -e "puts $0"
> -e:1: undefined local variable or method `bash' for main:Object (NameError)
> --->8---
__FILE__ is what I was thinking about. My second $0 test is stupid,
it's evaluated by bash before being passed to ruby...
"if __FILE__ == $0" might help.
Cheers,
lee....@gmail.com
> Hi Lee,
>
> BTW, where are you based ? I'm in Yokohama, Japan.
I'm near Boston, MA, USA.
> You're right. What about a file semaphore (IIRC, as you suggested
> before). Or simply something that notices that the console is being
> triggered and not the application itself. $0 ?
Yes, I like that idea better, since with a file or DB semaphore I'd
have to worry about knowing when to remove that semaphore, when the
application quits, for example.
> Well, I rely on this behaviour in some of my applications (and also
> Nicolas). What about something like :
>
> scheduler.schedule_at(past_moment, :discard_past => true) do
> #whatever
> end
>
> When the parameter :discard_past is set to true, if the event is due
> for the past, it would not be executed at all (and the call would
> return null). :discard_jobs_in_the_past ?
>
> Would that suit you ? There's maybe a better name for that param.
I like the idea of an optional parameter very much. discard_past,
future_only, whatever. :-)
Thanks!
Lee
John Mettraux
On 7/20/07, lee....@gmail.com <lee....@gmail.com> wrote:
>
>
> I like the idea of an optional parameter very much. discard_past,
> future_only, whatever. :-)
http://rubyforge.org/tracker/index.php?func=detail&aid=12426&group_id=2609&atid=10026
I'll implement that very soon and release a pre-gem.
Best regards,
John Mettraux
On 7/20/07, John Mettraux <jmet...@openwfe.org> wrote:
>
> On 7/20/07, lee....@gmail.com <lee....@gmail.com> wrote:
> >
> >
> > I like the idea of an optional parameter very much. discard_past,
> > future_only, whatever. :-)
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=12426&group_id=2609&atid=10026
>
> I'll implement that very soon and release a pre-gem.
Hi,
it's implemented, test cases look fine. It's released as well :
http://rubyforge.org/frs/?group_id=2609
(http://rubyforge.org/frs/download.php/22992/openwferu-scheduler-0.9.12.826.gem)
Allow some time to the RubyForge before a "gem install".
Best regards, thanks for the feedback,