On Jun 21, 12:50 am, EricHolmberg <[EMAIL PROTECTED]> wrote:
> I would like to have a background thread handle tasks such as sending
> notification emails and doing background integrity checks on the
> database. What is the best way to handle this? Possible solutions
> include:
>
> 1. Start a thread in load_environment
> 2. Run a separate daemon process
>
> Thread in load_environment
> ---------------------------------------
> This works great for the stand-alone Pylons server daemon, but I will
> be using mod_wsgi in the production system which results in multiple
> instantiations of the Pylons app, so multiple threads will be
> created. Should I just use this method and configure mod_wsgi to only
> start one instance of Pylons?
>
> Run a separate daemon process
> -----------------------------------------------
> This takes advantage of process isolation, but it will require
> checking to ensure that the daemon process is still running. Is there
> a way to have Apache do this background check? Any other solutions?
If using mod_wsgi you can do this by configuring a daemon process
group with a single process, specifying that a specific script file
should be run when that process is started, and then simply never
directing any requests to that process.
Thus, the daemon process definition might look like:
WSGIDaemonProcess mybackgroundtasks processes=1 threads=1
We set threads=1 simply so that minimum number of handler threads are
created in pool. The threads will never actually be used as we will
never direct any requests to it.
To have specific code executed when this daemon process is started,
define:
WSGIImportScript /some/path/script.wsgi process-
group=mybackgroundtasks application-group=%{GLOBAL}
In other words, when background tasks daemon process is started, in
the main Python interpreter context load the Python code in /some/path/
script.wsgi. Such code will be executed as if code file was a module
and imported.
To execute a background task, that script file would load threading
module, create a thread and run it with your code. A background thread
is still used as script must return.
And that is it.
Because this is a managed mod_wsgi daemon process, there is no need
for using separate supervisor as Apache/mod_wsgi will manage process
for you. As a result, the process will be started, stopped and
restarted as Apache is triggered to do the same. If the process
crashes for some reason, Apache will restart it automatically.
Note that the above is only necessary if running your WSGI application
if mod_wsgi embedded mode or a multiprocess daemon mode configuration.
That is, where multiple processes. If you were running your WSGI
application in single multithreaded daemon process, you could just the
above in same process as you were using for web application.
Even if WSGI application running in embedded mode or multiprocess
daemon mode configuration, you could still send subset of URLs to this
single background task process. In other words, the background task
process could itself be a mini web application, thus allowing you to
control through the web the background tasks it is performing.
Thus you might have:
WSGIScriptAlias /tasks /some/path/taskapp.wsgi
WSGIScriptAlias / /some/path/mainapp.wsgi
<Location /tasks>
WSGIProcessGroup mybackgroundtasks
</Location>
In summary, you can do what you want with just mod_wsgi, you do not
need to separately exec a back end process managed under supervisor or
similar system.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
