[uWSGI] Problem with multiple processes with httplib.HTTPConnection?

Alan Castro alanclic at gmail.com
Tue Nov 9 19:35:42 CET 2010


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 <roberto at unbit.it> 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 <roberto at unbit.it>
> 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
> >> uWSGI at lists.unbit.it
> >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >>
> > _______________________________________________
> > uWSGI mailing list
> > uWSGI at lists.unbit.it
> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >
>
>
> --
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> uWSGI mailing list
> uWSGI at lists.unbit.it
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.unbit.it/pipermail/uwsgi/attachments/20101109/d2d0e742/attachment.htm 


More information about the uWSGI mailing list