It's not the scheduler code that has changed/improved, it's a major change
in DAL code that needed some tune-ups. That same change in DAL needs to be
tested throughly, but I think nightly builds will come soon.
On Sunday, October 7, 2012 8:44:04 PM UTC+2, Adi wrote:
>
> Oh Niphlod :) No, I wasn'
Oh Niphlod :) No, I wasn't aware of that...
In that case it works as expected :) I created a new db, and introduced a
return value, which caused a record into into scheduler_run with status
"COMPLETED", and additional details in "result" field. This is perfect...
Thank you very much for scheduler
are you aware that if your task doesn't return nothing and doesn't go into
exception the new scheduler will erase the scheduler_run record ?
On Sunday, October 7, 2012 7:57:52 PM UTC+2, Adi wrote:
>
> The task executed properly, marked status "COMPLETED" in scheduler_task
> table, but didn't ins
The task executed properly, marked status "COMPLETED" in scheduler_task
table, but didn't insert a record into scheduler_run table. I will create
a new mysql database and let you know if the problem is there...
On Sun, Oct 7, 2012 at 2:12 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote
Can you please check the latest trunk and let us know if the problem has
gone?
On Friday, 5 October 2012 19:39:50 UTC-5, Adi wrote:
>
> Yes, new application was using the existing database, so fixing broken
> migration fixed the problem of not executing task. Now it executed and
> marked status
Yes, new application was using the existing database, so fixing broken
migration fixed the problem of not executing task. Now it executed and
marked status as COMPLETED. The problem with scheduler_run table stayed the
same. Status: FAILED, and traceback looks as bellow:
Traceback (most recent
ok, the problems seems to be related to migrate, migrate_enabled and
fake_migrate_all. Can you try removing those from the db connection just to
try it out ?
--
while I test it, could you please verify that when you updated web2py the
scheduler_* table have been migrated too ?
it seems in all your code posted migration on that db are always turned
off.
please inspect the scheduler_task table and see if it has a column named
"uuid".
BTW: from scheduler
Of course. This is what I have in a test application:
Models
==
db.py
if not request.env.web2py_runtime_gae:
# used tunnel
*db_s = DAL('mysql://crm:password@localhost:3307/CRM',migrate_enabled=
False, fake_migrate_all=True)*
else:
## connect to Google BigTable (optional 'google:d
Can you share some code so we ret reproduce it and fix it? We do not need
all the code. Just a minimalist example that causes the same problem.
On Friday, 5 October 2012 16:24:11 UTC-5, Adi wrote:
>
> yes, i just confirmed by running in parallel 9/13 and 10/5
>
> results:
> 9/13 partially works (
To summarize:
1) 9/13 version works
2) 10/4 version does not work as you expected
Did you try any 10/5 version?
On Friday, 5 October 2012 10:21:46 UTC-5, Adi wrote:
>
>
> for what it's worth, just want to let you know that after rolling back to
> "Version
> 2.0.9 (2012-09-13 23:51:30) stable"
for what it's worth, just want to let you know that after rolling back to
"Version
2.0.9 (2012-09-13 23:51:30) stable" tasks are getting executed, marked as
COMPLETED, but schedule_run is being marked as FAILED w bellow specified
sys.exit(1).
anyway... this is perfect for now, and customers
Created a new application from admin panel, accessing single mysql db,
inserted one task that sends an email and prints a test message.
Version 2.0.9 (2012-10-04 20:17:03) dev
def test():
db.scheduler_task.insert(
status='QUEUED',
a
Will run more tests in the morning on a brand new application, since I
can't see anything wrong (connection string duplication) in code right now.
Unfortunately, can't roll back this functionality now, so will have to
figure it out quickly. Thanks for help Massimo and Niphlod.
On Thu, Oct 4, 2012
No. this should not be a problem. This is only be a problem if any two have
the same connection string.
On Thursday, 4 October 2012 21:10:58 UTC-5, Adi wrote:
>
> I'm using 6 connections at the same time, 3 go to different databases on
> the same server, and 3 to totally different servers. Each
I'm using 6 connections at the same time, 3 go to different databases on
the same server, and 3 to totally different servers. Each connection has a
different name
db = DAL('mysql://crm:password@localhost:3307/CRM',migrate_enabled=True)
db_us =
DAL('mysql://web_US:password@localhost:3307/DataUS',m
This error can arise in two cases:
- you are using an a recent trunk version (not the latest) which has a bug
- you are using the latest trunk (no bug) but you have a duplicated
connection in your code:
db = DAL()
db = DAL()
perhaps in different model files. Previous web2py did not check
Still the same problem:
Traceback (most recent call last):
File "/opt/web-apps/web2py/gluon/scheduler.py", line 203, in executor
_env = env(a=a,c=c,import_models=True)
File "/opt/web-apps/web2py/gluon/shell.py", line 134, in env
sys.exit(1)
SystemExit: 1
Is there any line of code that
update to trunk, the problem is fixed. PS: Nightly build generally are
stable, but a few times (like the ones with potentially hige impacts - like
last changes made in DAL initialization) are, nonetheless, for testing
purposes, not production ready!
On Thursday, October 4, 2012 9:42:59 PM UTC+2
can you try again the latest?
On Thursday, 4 October 2012 14:42:59 UTC-5, Adi wrote:
>
> We promoted latest night build to production, and scheduler started
> failing. At the same time there were some code changes, so I'm having a
> hard time tracing the source of the problem.
>
> Any insights w
20 matches
Mail list logo
