let's go with order .....
 

> "production server" - nginx serving my website. db connects to a mysql 
> instance bound to production server network address. scheduler connects to 
> mysql instance running on the "dev/workq server"
> "dev/workq server" - nginx serving a copy of the same web2py 
> directory...plan to use as development server if needed as well.  db 
> connects to mysql instance running on production server. scheduler connects 
> to mysql instance bound to dev server network address.
>

so you have two databases, one on the prod and one on the dev. 
The db for the webapp is always pointing to the prod server (regardless of 
who is running the webapp) and the db for the scheduler is always pointing 
to the dev one (regardless of who is running the scheduler), correct ?
 

>
> from 0_db.py:
> db = DAL('mysql://dev:xxx...@production.server.edu/myapp
> ',pool_size=8,check_reserved=['mysql'],migrate=ENABLE_MIGRATE,fake_migrate_all=ENABLE_FAKE_MIGRATE)
>
>
>
> from scheduler.py:
> scheduler = Scheduler(DAL('mysql://workq:x...@dev.workq.server.edu/myapp
> ',pool_size=8,check_reserved=['mysql'],migrate=ENABLE_MIGRATE,fake_migrate_all=ENABLE_FAKE_MIGRATE),heartbeat=2)
>
>
>
>  
this seems right, although I'd have preferred a simple
db2 = DAL('mssql://dev.work.server....')
sched = Scheduler(db2)
BTW: Scheduler has a migrate argument for itself as Auth does.
 

>
> My steps from empty mysql databases and database directories on both 
> servers and both mysql instances.
> - go to site on the production server - migrate = True, fake_migrate = 
> False -> OK
> - go to site on the dev server - migrate = True, fake_migrate = False -> 
> Error - <class 'gluon.contrib.pymysql.err.InternalError'> (1050, u"Table 
> 'auth_user' already exists")
>
 
this is expected. dev has no .table files but tables were created by the 
prod app. Next step is the correct way to fix the issue. Assuming that the 
dev app has notion of the scheduler, scheduler tables were created too by 
the prod app. 

- go to site on the dev server - migrate = False, fake_migrate = True -> OK
> - start scheduler task -> OK
>
> *Am I starting this all up improperly?  I'm a little confused since I've 
> got two web2py instances talking to different db instances for the web app 
> and the scheduler...but I think having to do a fake migrate on the second 
> server makes sense.*
> *
> *
>
Makes perfect sense. BTW, once the tables are created you **should** turn 
migration to False to avoid unnecessary overhead.
 

> **
> *
> *
> So now I *think* my website is up and running properly.  I then run a 
> function that schedules a job.  This seems to run (by looking at the 
> comfortscheduler monitor), but it's supposed to schedule additional jobs 
> itself.  This never happens.
>
>
> inside the single task that is scheduled and runs:
>
> for items in my_thing:
>
>   #...do stuff
>
>   # Submit tasks to process more stuff
>   print "submitting job \n"
>   scheduler.queue_task(my_task2,timeout=60000,
>     pvars=dict(arg1= arg1,
>     arg2=arg2))
>   
>   db(db.collections.name == collection).update(last_id=last_id)
>   db.commit()
>
>
>  
Here lies the error. Inside the task you're committing for the "main" 
webapp db and not on the "scheduler" one. Assuming you did as I told before 
(having a separate db2 DAL instance), you need to do also db2.commit(), 
else the task will run ok but it will never commit the records to the 
scheduler_task table.
 

>
> *If I try to view the details of the task in the ComfortScheduler monitor 
> (from my production server) by clicking on the UUID link of the task i get 
> an error:*
>
> <type 'exceptions.AttributeError'> 'DAL' object has no attribute 
> 'scheduler_task'
>
> This shouldn't happen. ComfortScheduler retrieves the db of the scheduler 
from the scheduler instance itself.

s = current._scheduler
dbs = s.db
st = dbs.scheduler_task
sw = dbs.scheduler_worker
sr = dbs.scheduler_run
 
However ComfortScheduler has been battle-tested only by me (AFAIK) and 
there could be errors.... The main "strange thing" here is that if the page 
successfully generated "the link" for the task, it should access the task 
in the same exact way.
Can you provide more details and/or a screenshot ? It may be very well be a 
bug in the code of the plugin.


Anyone have a server config like this before?
>

Not precisely the same but the "same". Having different DAL instances is 
totally supported. Even in w2p_tvseries there are two dbs, one for the 
webapp and one for the scheduler only. Works like a charm as intended.


-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to