this is in trunk. Option 3. Please check it. Mind that if a cron process gets stuck option 3 causes a proliferation of processes that will eventually crash the machine.
On Mar 1, 9:26 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > 3 > > -Thadeus > > On Mon, Mar 1, 2010 at 5:42 AM, Álvaro Justen [Turicas] > > <alvarojus...@gmail.com> wrote: > > On Mon, Mar 1, 2010 at 05:03, AchipA <attila.cs...@gmail.com> wrote: > >> 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. > > > +1 > > >> 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 > >> athttp://groups.google.com/group/web2py?hl=en. > > > -- > > Álvaro Justen - Turicas > > http://blog.justen.eng.br/ > > 21 9898-0141 > > > -- > > 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 > > athttp://groups.google.com/group/web2py?hl=en. -- 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.
