Ah, a possible limitation of implementing option 1 from option 3, however, would be that the number of threads/processes (depending on which one is used for the jobs here) would increase linearly during execution.
Not so bad if exceeding 15 minutes only happens occasionally (and the task takes a lot less than 10 minutes to execute the rest of the time to compensate), but pretty problematic if an unforeseen situation causes a task that was foreseen to take less than 10 minutes actually take 15 minutes or more on a regular basis. Assuming that being able to implement option 1 is a must, a solution to this problem would be to allow the programmer to change the time interval between tasks at run time. On Mar 1, 5:34 am, Magnitus <eric_vallee2...@yahoo.ca> wrote: > I'd lean toward option 3 as the default behavior also as its the most > flexible and allows the programmer to handle the situation as his > application requires. > > From that, option 1 and 2 can be implemented by the user using a flag > and a mutex. > > On Feb 28, 11:27 pm, 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- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- 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.
