Sorry for the slow reply, been a rather hectic week. On 31 Mar 2015, at 12:40 am, Jeff Sheffield <[email protected]> wrote:
> Hello, > > I am maintaining a django application that uses the older http-longpoll > technique, yielding data back to the client. > I would like coordinate that a bit with an additional message broker message > > Problem: Have a client session/django app: fire off 2 synchronized threads > sharing data. > > Thread-one: listens to a dbms for notifications and writes a shared_buffer[] > when data arrives > and > Thread-two: listens to a message broker for a message, and flushes (yields) > the shared_buffer[] when > an appropriate message arrives to the broker. > > My question is: should I be configuring WSGIDaemonProcess or should I be in > embedded mode? The basic problem is that you have a requirement where multiple requests pertaining to the same session must end up being served by the same process. In a multiprocess configuration this is not guaranteed. Thus you definitely cannot use embedded mode with prefork MPM, nor embedded mode with worker MPM if the MPM configuration would still result in more than one worker process. So if using embedded mode, you would have to use worker MPM, but configure it that you had a maximum of one Apache child process. If using daemon mode, what MPM is used wouldn’t matter too much, but the daemon process group would similarly have a maximum of one process. In both scenarios, because if it is a long poll style application with a connection which is open for some time, you would have to have a high number of threads if you need to deal with a high level of concurrent requests. Your situation seems to be made worse by the idea that you would create additional standalone threads within the process to do work for a specific session. In general a long poll application or anything else that needs to handle a large number of current long running connections is best not handled by a WSGI server which uses processes/threads alone for concurrency. One would tend to use a event driven async Python web server such as Tornado. One might be able to get away with gevent/eventlet based servers which use green let coroutines, but whether they can be used depends on other factors and whether it all blocking code you have in your application, or in third party service client modules is or can be made coroutine aware. So my initial impression is that you design and the use of long polling would not be suited for a traditional process/thread based WSGI server. > I want to avoid having the shared_buffer[], shared between two web-client > sessions, which I believe will be > in the same thread pool if I configure in WSGIDaemon mode. Am not sure what you mean by this. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
