idle connection are one thing and they can be fine. idle in transaction, usually happens when there is a missing commit and the transaction stays open, delivering all sorts of locking over the long term usually a commit or rollback before the fork should solve the problem.
2015-02-18 23:09 GMT+01:00 Niphlod <niph...@gmail.com>: > 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. > -- 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.
