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.
