3 is the correct choice for several reasons. If the jobs should not overlap, it's the scripts reponsibility to provide a check and react accordingly. IMHO Cron should not skip tasks or change the start time voluntarily (it's not a resource manager). Also, 3 is how the 'real' cron works.
On Mar 1, 5:27 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > follow up... > > one thing is not clear to me. Say a cron job should start every 10 > minutes. If the actual execution of the job takes longer (say 15 > minutes) what is the right thing to do? > 1) Queue them (thus running every 15 minutes but the size of the queue > gets longer and longer)? > 2) Skip an extra ten minutes (thus running in effect only once every > 20 minutes)? > 3) Start them anyway (and assume they will not conflict with each > other)? > > I am leaning for option 3. > > On Feb 28, 10:22 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > I discovered a race condition problem in web2py cron. This may cause > > spikes in the number of web2py processes and eat lots of memory on > > your system when running multiple processes. Some of you have reported > > the problem. > > > I changed wsgihandler in trunk and replaced > > > from gluon.contrib.wsgihooks import ExecuteOnCompletion2, > > callback > > application = ExecuteOnCompletion2(gluon.main.wsgibase, callback) > > > with > > > application = gluon.main.wsgibase > > > thus disabling cron by default in this situation. > > > I think this problem can be fixed by using file locks instead of the > > current cron.py locking mechanisms. I am close to a solution and will > > post it tomorrow. > > > Massimo -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
