reloading application

[Milan Andric]

I am trying to understand when/how code changes get propogated to
mod_wsgi. It would be ideal if when some code in my application
changes (like modifying a Django models.py file) I can tell mod_wsgi
to reload the application. I tried to force application reload using
apache graceful/restart/stop and start or editing/touching
dispatch.wsgi but the changes are not loaded.

Is there a way to automate the process of reloading the application or
to force mod_wsgi to reload it? I have mod_wsgi configured in the
following way:

$ cat ~/public_html/.htaccess
#Options -Indexes
RewriteEngine On
RewriteBase /
RewriteRule ^(media/.*)$ - [L]
RewriteRule ^(admin_media/.*)$ - [L]

# rewrite everything else to disptach.fcgi
RewriteRule ^(dispatch\.wsgi/.*)$ - [L]
RewriteRule ^(.*)$ dispatch.wsgi/$1 [QSA,PT,L]

$ cat ~/public_html/dispatch.wsgi
#!/opt/local/bin/python

import os, sys
sys.path.insert(0,'/home/mandric/dev/knight/sites/multimedia/lib')
os.environ['DJANGO_SETTINGS_MODULE'] = 'journalism_mm.settings'
os.environ['PYTHON_EGG_CACHE'] = '/home/mandric/dev/python-eggs'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

And in httpd.conf:
LoadModule wsgi_module /usr/local/apache/modules/mod_wsgi.so
AddHandler wsgi-script .wsgi

Thanks!

--
Milan

[Milan Andric]

It looks like I'm mistaken I was making a change that I didn't
notice. So as expected when the application code changes mod_wsgi
just seems to know about it. Amazing! No signals need to be sent to
apache!

--
Milan

[Graham Dumpleton]

2008/7/10 Milan Andric <man...@gmail.com>:

>
> It looks like I'm mistaken I was making a change that I didn't
> notice. So as expected when the application code changes mod_wsgi
> just seems to know about it. Amazing! No signals need to be sent to
> apache!

It should only notice when .wsgi file is changed, not arbitrary code,
but then what happens depends on which mode you are using. See:

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

Graham

[Milan Andric]

On Wed, Jul 9, 2008 at 8:37 PM, Graham Dumpleton
<graham.d...@gmail.com> wrote:
>
> 2008/7/10 Milan Andric <man...@gmail.com>:
>>
>> It looks like I'm mistaken I was making a change that I didn't
>> notice. So as expected when the application code changes mod_wsgi
>> just seems to know about it. Amazing! No signals need to be sent to
>> apache!
>
> It should only notice when .wsgi file is changed, not arbitrary code,
> but then what happens depends on which mode you are using. See:
>
> http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
>
> Graham

I am not using the WSGIScriptAlias directive, but only the apache
directives with the corresponding .htaccess file that I posted
earlier.

LoadModule wsgi_module /usr/local/apache/modules/mod_wsgi.so
AddHandler wsgi-script .wsgi

I'm new to mod_wsgi and was surprised that with this configuration no
restart on apache is needed to reload code. When I make a change in a
class method or add an attribute the new code is just loaded on a new
request. This is with mod_wsgi 2.0.

--
Milan

[Milan Andric]

But sure enough when I use WSGIScriptAlias this doesn't hold up. As
documented, I need to modify/touch the wsgi script (dispatch.wsgi) to
get my changes to load.

Anyway, the result when using the previously specified .htaccess setup
was unexpected. Sorry I can't offer more information to help debug.

--
Milan

[Graham Dumpleton]

2008/7/24 Milan Andric <man...@gmail.com>:

Using WSGIScriptAlias or using AddHandler makes no difference.

The important thing is whether you are using embedded mode or daemon
mode. As per documentation, in embedded mode, only the script file is
reloaded, not the whole application. You appear to be using embedded
mode. If you thought the whole application was being reloaded, more
likely that request was being handled by new Apache child process.

Suggest you try daemon mode, ie., WSGIDaemonProcess/WSGIProcessGroup,
and see how it behaves. Embedded mode can be confusing because of the
fact that Apache can create new child processes when it feels like it,
thus making it appear code is reloaded for an existing process when it
wasn't.

Graham

[Milan Andric]

On Wed, Jul 23, 2008 at 8:50 PM, Graham Dumpleton

Thanks Graham -- I realized this after posting and things are making
more sense now. I found this link which explains things quite well
from a beginners perspective. It's a little tricky to get a bigger
picture just looking at the technical documentation.
http://groups.google.com/group/modwsgi/browse_thread/thread/60cb0ec3041ac1bc/2c547b701c4d74aa

Now I'm wondering whether my application is thread-safe. Guess I can
just try and see. ;)

--
Milan

[Milan Andric]

Is this an example of some code that is not thread safe?

http://dpaste.com/67102/

I'm debating whether I should try to fix some code before I move to my
wsgi setup.

Comments appreciated.

--
Milan

[Graham Dumpleton]

Is pdfpath the same for every request? If it is, that would be a
problem in multithreaded application.

Graham

[Nimrod A. Abing]

On Thu, Jul 24, 2008 at 10:38 AM, Milan Andric <man...@gmail.com> wrote:
> Is this an example of some code that is not thread safe?
>
> http://dpaste.com/67102/

If tutorial.get_pdf_filepath() returns the same value for each call,
then that is not thread-safe.

> I'm debating whether I should try to fix some code before I move to my
> wsgi setup.
>
> Comments appreciated.

1. pdfpath = tutorial.get_pdf_filepath() - If you look at your formal
parameters for your function, you have tutorial as an optional
parameter which defaults to False. You should at least handle the case
where tutorial is False (or None) and use pdfpath with a sane value.

2. os.system() is better replaced with subprocess.Popen() in this
case. See http://www.python.org/doc/current/lib/node533.html
os.system() requires the use of your default OS shell,
subprocess.Popen() does not. You get consistent results between
platforms in addition to a lot things that are not available using
os.system() like being able to redirect stderr and stdout, output
buffering, changing the cwd, creating an alternate set of environment
variables for the subprocess, etc.

3. "print" statements. You're better off using "print >> sys.stderr"
just in case you forget to unset "DEBUG" in production when you are
already running mod_wsgi. Your code probably has a lot of this spread
around and they can be very hard to track down.

4. "generates cleaner PDFs than ReportLab rendering from the htmldoc
script" - that's debatable :)
--
Best Regards,
Nimrod A. Abing

W http://arsenic.ph/
W http://preownedcar.com/
W http://preownedbike.com/
W http://abing.gotdns.com/