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.
