Hi Roberto, I tried uwsgi last last version with --threads and the current stable with -T and the problem still occurs..
The real problem is SQLAlchemy + Pylons + Multi-process. Summaryzing: There are 2 situations where everything works: * when I comment out the every db related code and deploy on a 'multi-process environment'. * and if I use a '1 process environment' with db related code. And 1 situation (the one I really wanted to work) that does not work: * 'multi-process environment' with db related code. Thanks Alan On Tue, Nov 9, 2010 at 3:55 PM, Roberto De Ioris <[email protected]> wrote: > > > I just deployed with the current version of mercurial and when i use -T > > option my app won't work. (without -T it works) > > > > The "ready_to_reload..." is a normal debug info? > > > > Please try the -T with the current stable releases, and --threads <n> > (use a low number like 4) with the mercurial one > > > > > Thanks > > > > Alan > > > > On Tue, Nov 9, 2010 at 3:05 PM, Roberto De Ioris <[email protected]> > wrote: > > > >> > >> Il giorno 09/nov/2010, alle ore 17.39, Alan Castro ha scritto: > >> > >> > Roberto, > >> > > >> > I'm still facing this problem. > >> > > >> > Let me context my problem: I developed a Pylons application (which is > >> multithreaded, each request fires up a new thread) and is working fine > >> (deployed with uwsgi with one process). When I run it on a multiprocess > >> with > >> uwsgi eveything goes out of control and I keep getting this Oracle error > >> TNS: Bad packet, which looks like problem with my sqlalchemy session > >> object. > >> > > >> > I know this runs a bit out of uwsgi context, but do you know how much > >> uwsgi multiprocess environment affects pylons multithreaded? In my head > >> everything should work fine. > >> > > >> > >> I suppose that your app generate a new python thread at every request > >> that > >> do something in the background and pass data to the "main" thread that > >> will > >> send the response to the webserver; in this case, have you enabled the > >> -T > >> option ? > >> Without it the GIL is not initialized and i do not know what could > >> happen > >> :) If instead your app generate a new thread that "alone" manages the > >> whole > >> request > >> (so the thread itself generate the wsgi response) this will cause all > >> sort > >> of problems, as the current uWSGI stable releases are not multithreaded > >> (you > >> have to use > >> a 0.9.7-dev release from mercurial repository) > >> > >> -- > >> Roberto De Ioris > >> http://unbit.it > >> > >> _______________________________________________ > >> uWSGI mailing list > >> [email protected] > >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > >> > > _______________________________________________ > > uWSGI mailing list > > [email protected] > > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
