I actually get an error using your trick: Traceback (most recent call last): File "gluon/scheduler.py", line 1512, in <module> main() File "gluon/scheduler.py", line 1506, in main utc_time=options.utc_time) File "gluon/scheduler.py", line 588, in __init__ self.define_tables(db, migrate=migrate) File "gluon/scheduler.py", line 613, in define_tables from pydal.base import DEFAULT ImportError: No module named pydal.base
Thanks for your help anyway Niphlod. But maybe I wasn't being very clear when I mentioned the connections being "idle in transaction" rather than just "idle". I did find a work-around! I segregated scheduler functions into its own application. A dedicated application for scheduler meant scheduler would only hold a single connection to its own dedicated database. No more locks accessing the other 2 databases so everything works quite well now :) On Wednesday, February 18, 2015 at 2:09:22 PM UTC-8, Niphlod wrote: > > 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.