uhm^3. The code is quite unfixable as it is (launching scheduler with web2py.py -K appname). Remember that the only thing I'm trying to fix is the main process using idle connections to all databases defined in the models of you app.
However, there's a small unknown trick: the scheduler can be started on its own, and process happily tasks defined in applications, as long as they are reachable from within the path you're launching it. The former translates to: if you are on the same path web2py is in, you can use another commandline to launch the scheduler, whose main process will only be aware of the "db_sched" connection. Small fixes are needed to make the "unknown trick" work again (up until now the "trick" hasn't been tested much) but the working file is here <https://www.dropbox.com/s/3lumrofqcp1bxyq/scheduler.py?dl=0> . You should start as cd web2py # <<-- path where web2py.py is python gluon/scheduler.py -u *uri_of_the_db* -f *folder* -L 0 -b 2 where: - *uri_of_the_db* is the database uri (i.e. *postgresql://.....*, mind that for sqlite, you should pass the entire relative path, as in *sqlite:///applications/appname/databases/storage.sqlite*) - *folder* is the relative folder where the database tables are (i.e. *applications/appname/databases/* ) - the number after -L is the logging level (0 all, 100 nothing) - the number after -b is the heartbeat in seconds Please try it and see if the idle connections are still there or not. On Wednesday, February 18, 2015 at 10:04:45 PM UTC+1, Niphlod wrote: > > uhm, the problem is more subtle......... > > The main process of the scheduler is like a shell opened on that > application....... it needs to reads models to see the scheduler > definition. I guess that this means that it will also connect to all the > databases defined in models, even if it will effectively send/receive > commands only on the scheduler_db. > Those "additional" connections are not needed as a matter of fact, but > shouldn't block anything too: they're idle and never used. > > Every spawned process (the one that will process the task) needs to > execute models, else your task won't be able to access, e.g. "db", and, to > be fair, they won't be able to "see" the tasks definitions in the first > place. Those connections are used, but the connections are kept open just > for the time the task gets processed (the spawned process dies as soon as > the task finishes). > > Let me check if there is a workaround for the connections on the main > process. I'll get back to you (at most in a few days) > > -- 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/d/optout.
