web2py 1.76.2 is OUT

[mdipierro]

Main changes include:

1) major fix in cron (will I ever get this 100% right?)
2) auth.settings.login_captcha and auth.settings.register_captcha
3) crud.settings.create_captcha and crud.settings.update_captcha
4) automatic update button in admin

4) needs testing. To test-in:

- make a fresh web2py installation
- located the file VERSION (under web2py/ on Win and under web2py.app/
Contents/Resources/ on Mac)
- edit this file with a editor and set it to something old like 1.0.0
- restart web2py
- in admin/default/site click on "upgrade web2py"
- restart web2py
- did it work?

Please let me know.

[mdipierro]

made a build error. re-posting as 1.76.3. sorry.

[mr.freeze]

You might need to repost again. auth and crud captcha had problems.

[mdipierro]

nobody downloaded it so I did and preserved the number.

[mr.freeze]

Bad news. Cron errors on Windows running from source:

Exception in thread Thread-22:
Traceback (most recent call last):
File "c:\Python25\lib\threading.py", line 486, in __bootstrap_inner
self.run()
File "C:\Users\me\workspace\web2py\gluon\contrib\cron.py", line 81,
in run
if 60 <= now - self.cronmaster: # new minute, do the cron dance
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

[mdipierro]

grrrr. as the changelog above said:

1) major fix in cron (will I ever get this 100% right?)

Anyway, please check it in trunk.

[mr.freeze]

I forgot to mention, I only get the error when I have cron=False in
web2py.py. Sorry. There is no error when cron=True.

[mdipierro]

Check if it works anyway.

[mr.freeze]

No errors.

[Rowdy]

mdipierro wrote:
> grrrr. as the changelog above said:
>
> 1) major fix in cron (will I ever get this 100% right?)
>
> Anyway, please check it in trunk.

I did not get a chance to test cron changes in trunk before the 1.76.3
release.

Thank you for the speedy responses and update.

I have had a look at the 1.76.3 cron, and have the following
observations.

1. The "execute every minute" problem is fixed :-)

2. The spelling error is still there "CRON Call retruned success" should
be "returned"

3. There is a problem with acquiring a lock. Not a web2py problem
particularly. As I understand it, Token.acquire() in cron.py checks
whether the last time cron started was more than 60 seconds ago. If
not, it does not try to acquire a lock, and the whole cron cycle
silently aborts (crondance(): if not cronmaster: return) until the next
minute.

What I am seeing with a few extra debug statements is that while
acquiring a lock and testing "self.now - start >= 60" sometimes the
calculation is like 60.0000019073 and sometimes like 59.9999949932.
This seems to happen fairly randomly, so occasionally, but repeatably,
cron thinks the last execution was 59.999 seconds ago, and does not
start up. The next time thru the time difference is like 119.999917984
seconds, so the next cron does start.

How about changing the test for >= 60 seconds to >= 59 seconds in
Token.acquire()? I tried that and, although it is difficult to state
authoritatively that it works forever, running my 5 minute and 10 minute
cron jobs for an hour or so has reliably run each job at the scheduled
times.

Rowdy

[mdipierro]

Let's make it 59.99 then. We want to avoid false positives more than
false negatives.

[Rowdy]

mdipierro wrote:
> Let's make it 59.99 then. We want to avoid false positives more than
> false negatives.
>

Sounds good.

Over the past 2.5 hours the smallest value I saw was 59.9909880161.

Rowdy

[mdipierro]

ok, in trunk. Thanks for your help with this.

[Rowdy]

mdipierro wrote:
> ok, in trunk. Thanks for your help with this.
>
> On Mar 3, 8:42 pm, Rowdy <da...@fielden.com.au> wrote:

Bad news. I left it running overnight with the 5 and 10 minute jobs and
the check for >= 59 seconds, logging the extra debug messages.

The lowest values for the interval were (these are just the debug
messages where I log the values used in the calculation and comparison):

DEBUG:root: self.now - start = 59.4419999123 (sb >= 59)
DEBUG:root: self.now - start = 59.7331020832 (sb >= 59)
DEBUG:root: self.now - start = 59.8089871407 (sb >= 59)
DEBUG:root: self.now - start = 59.9066801071 (sb >= 59)
DEBUG:root: self.now - start = 59.9478530884 (sb >= 59)
DEBUG:root: self.now - start = 59.9600059986 (sb >= 59)
DEBUG:root: self.now - start = 59.9605009556 (sb >= 59)
DEBUG:root: self.now - start = 59.9644701481 (sb >= 59)
DEBUG:root: self.now - start = 59.9700820446 (sb >= 59)
DEBUG:root: self.now - start = 59.9701111317 (sb >= 59)
DEBUG:root: self.now - start = 59.9742279053 (sb >= 59)
DEBUG:root: self.now - start = 59.9745769501 (sb >= 59)
DEBUG:root: self.now - start = 59.9763190746 (sb >= 59)
DEBUG:root: self.now - start = 59.9764039516 (sb >= 59)
DEBUG:root: self.now - start = 59.9764339924 (sb >= 59)
DEBUG:root: self.now - start = 59.9844388962 (sb >= 59)
DEBUG:root: self.now - start = 59.9874939919 (sb >= 59)
DEBUG:root: self.now - start = 59.9896328449 (sb >= 59)
DEBUG:root: self.now - start = 59.9899420738 (sb >= 59)
DEBUG:root: self.now - start = 59.9899940491 (sb >= 59)
DEBUG:root: self.now - start = 59.9899971485 (sb >= 59)
DEBUG:root: self.now - start = 59.9899971485 (sb >= 59)

Testing for a delay of 59.99 seconds would mean that any cron jobs
scheduled to run on the above 22 occasions would not run as
Token.acquire() would not obtain a lock.

To me this is significant, as the possibility exists that a once a day
job might fall on an execution time where the interval is between 59 and
59.99 seconds (as in the above 23 seconds) and not run. When cron
starts up a minute later, the job has lost its opportunity to run, and
that day is skipped (for the once a day job).

I have not started writing the cron jobs for my app yet (there are about
a dozen), so I will see how it goes when the jobs are in place.

But the main problem with jobs running every minute and regularly
skipping have been solved.

Thanx again.

Rowdy

[mdipierro]

Let's think about this some more....