It is highly recommended that all users of Apache 1.3 and Apache 2.0 upgrade to this version as it includes a fix for an issue whereby if default for WSGIApplicationGroup is used, or %{RESOURCE} is used, that particular URLs could result in a second Python sub interpreter instance being created for each resource/application. This would have the affect of doubling the amount of memory in use for that application which in a constrained memory environment could cause physical memory to be used up and swapping to occur, or cause you to unexpectedly reach any VPS memory limit. This issue does not affect users of Apache 2.2.
This should only be used by those who like to test out the latest version and give feedback.
Primary thing of interest in this version is 'Process' option for WSGIReloadMechanism to make it easier to restart an application running in a mod_wsgi daemon process when code changes are made. When enabled, only need to touch the WSGI script file when you want application to be reloaded.
Other significant changes include ability to hook into Apache 2.2 auth provider mechanism, support for Python virtual environments and the beginning of some hooks to be able to work with the internal Apache APIs. Check out the changes file for further details.
Bernd and Adal, feel free to make Debian and Windows binaries. The 2.0c1 version should probably target just the unstable tree of Debian release tree.
On 10/30/07, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> Bernd and Adal, feel free to make Debian and Windows binaries. The > 2.0c1 version should probably target just the unstable tree of Debian > release tree.
I've made available a Mercurial repository of my Portage overlay, which currently only contains a mod_wsgi-1.2 ebuild. You can clone it or download a tarball from the web, at http://hg.xavamedia.nl/portage/.
I have updated the Windows binaries. The 2.0c1 version builds only after moving the "DispatchObject *adapter = NULL;" declaration from around line 5495 to the start of the block.
Couldn't test them though.
I'm getting this error, can't figure out why since the path seems to be ok (and I can run "from paste.deploy import loadapp" in the CLI python). I'm not testing on my usual computer, so it could be a configuration problem.
mod_wsgi (pid=212, process='', application='127.0.0.1:90|'): Loading WSGI script 'X:/Project/Anim/Website/AnimWeb/anim.wsgi'. mod_wsgi (pid=212): Target WSGI script 'X:/Project/Anim/Website/ AnimWeb/anim.wsgi' cannot be loaded as Python module. mod_wsgi (pid=212): Exception occurred processing WSGI script 'X:/ Project/Anim/Website/AnimWeb/anim.wsgi'. Traceback (most recent call last): File "X:/Project/Anim/Website/AnimWeb/anim.wsgi", line 4, in <module> from paste.deploy import loadapp ImportError: No module named paste.deploy
> I have updated the Windows binaries. The 2.0c1 version builds only > after moving the "DispatchObject *adapter = NULL;" declaration from > around line 5495 to the start of the block.
> Couldn't test them though.
> I'm getting this error, can't figure out why since the path seems to > be ok (and I can run "from paste.deploy import loadapp" in the CLI > python). I'm not testing on my usual computer, so it could be a > configuration problem.
> mod_wsgi (pid=212, process='', application='127.0.0.1:90|'): Loading > WSGI script 'X:/Project/Anim/Website/AnimWeb/anim.wsgi'. > mod_wsgi (pid=212): Target WSGI script 'X:/Project/Anim/Website/ > AnimWeb/anim.wsgi' cannot be loaded as Python module. > mod_wsgi (pid=212): Exception occurred processing WSGI script 'X:/ > Project/Anim/Website/AnimWeb/anim.wsgi'. > Traceback (most recent call last): > File "X:/Project/Anim/Website/AnimWeb/anim.wsgi", line 4, in > <module> > from paste.deploy import loadapp > ImportError: No module named paste.deploy
BTW, if you are using WSGIPythonPath, create a hello world program which echos back sys.path. In looking at value for WSGIPythonPath I split it into separate directories and for Windows it should split on ';' and not ':', but if I am stuffing up somehow then any drive specifier could be causing an issue. Also, not sure whether I may have changed the behaviour in respect of how backslashes are treated. I could well have changed it inadvertently without realising.
So, look carefully at sys.path and adjust backslash escaping, or use forward slashes.
Graham
On 30/10/2007, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> This behaves a bit differently now and calls site.addsitedir() instead > of just setting PYTHONPATH environment variable. It may be screwing > things up.
> Graham
> On 30/10/2007, Adal Chiriliuc <adal.chiril...@gmail.com> wrote:
> > I have updated the Windows binaries. The 2.0c1 version builds only > > after moving the "DispatchObject *adapter = NULL;" declaration from > > around line 5495 to the start of the block.
> > Couldn't test them though.
> > I'm getting this error, can't figure out why since the path seems to > > be ok (and I can run "from paste.deploy import loadapp" in the CLI > > python). I'm not testing on my usual computer, so it could be a > > configuration problem.
> This behaves a bit differently now and calls site.addsitedir() instead > of just setting PYTHONPATH environment variable. It may be screwing > things up.
> Graham
> On 30/10/2007, Adal Chiriliuc <adal.chiril...@gmail.com> wrote:
> > I have updated the Windows binaries. The 2.0c1 version builds only > > after moving the "DispatchObject *adapter = NULL;" declaration from > > around line 5495 to the start of the block.
> > Couldn't test them though.
> > I'm getting this error, can't figure out why since the path seems to > > be ok (and I can run "from paste.deploy import loadapp" in the CLI > > python). I'm not testing on my usual computer, so it could be a > > configuration problem.
While preparing 2.0c1 for experimental we hit the following problem:
The 1.X packages were all built using the apache-threaded-dev package, which provides the necessary environment to build modules for all threaded workers (like apache-mpm-worker). So far the package suggested to use threaded workers and did not explicitly conflict with the apache-mkm-prefork, as mod_wsgi worked well in the preforking environment, even when it was built against the threaded-dev package.
With 2.0c1 I run into the problem that mod_wsgi doesn't work anymore if it was built using the threaded-dev, if you run it with the preforking worker. /usr/lib/apache2/modules/mod_wsgi.so: undefined symbol: ap_thread_stacksize Although this sounds obvious, the real problem for me is that I can't install apache2-prefork-dev and apache2-threaded-dev at the same time, which means I can't use them both as build-dependencies.
So the options I have now are:
- Build against -threaded-dev, conflict with the prefork worker. This will probably make the php lovers upset, as their broken ******* doesn't work with the threaded worker.
- Build against -prefork-dev. I didn't try if the module would work in the preforking environment, but that wouldn't make me happy anyway.
- Put the source of mod-wsgi into Debian twice (not an acceptable option, but I wanted to mention it).
- Build two packages and copy the apache-threaded-dev files into a temporary directory and patch them so they look like apache-prefork-dev and build against them. Pretty ugly way, and it needs to follow chances in the -dev packages.
- Ask the apache maintainer to modify the -dev packages so they're installable at the same time, probably using dpkg-alternatives, but this is not really an easy task, so I'm looking for alternatives first.
It is not critical. I was just trying to inherit stack size from ThreadStackSize directive. Just means that someone will need to set both ThreadStackSize and stack-size option to WSGIDaemonProcess. Since rare that this would required, not too concerned in dropping it if it causes problems.
Graham
On 31/10/2007, Bernd Zeimetz <be...@bzed.de> wrote:
> While preparing 2.0c1 for experimental we hit the following problem:
> The 1.X packages were all built using the apache-threaded-dev package, > which provides the necessary environment to build modules for all > threaded workers (like apache-mpm-worker). So far the package suggested > to use threaded workers and did not explicitly conflict with the > apache-mkm-prefork, as mod_wsgi worked well in the preforking > environment, even when it was built against the threaded-dev package.
> With 2.0c1 I run into the problem that mod_wsgi doesn't work anymore if > it was built using the threaded-dev, if you run it with the preforking > worker. > /usr/lib/apache2/modules/mod_wsgi.so: undefined symbol: ap_thread_stacksize > Although this sounds obvious, the real problem for me is that I can't > install apache2-prefork-dev and apache2-threaded-dev at the same time, > which means I can't use them both as build-dependencies.
> So the options I have now are:
> - Build against -threaded-dev, conflict with the prefork worker. This > will probably make the php lovers upset, as their broken ******* doesn't > work with the threaded worker.
> - Build against -prefork-dev. I didn't try if the module would work in > the preforking environment, but that wouldn't make me happy anyway.
> - Put the source of mod-wsgi into Debian twice (not an acceptable > option, but I wanted to mention it).
> - Build two packages and copy the apache-threaded-dev files into a > temporary directory and patch them so they look like apache-prefork-dev > and build against them. Pretty ugly way, and it needs to follow chances > in the -dev packages.
> - Ask the apache maintainer to modify the -dev packages so they're > installable at the same time, probably using dpkg-alternatives, but this > is not really an easy task, so I'm looking for alternatives first.
> [Wed Oct 31 00:50:42 2007] [info] mod_wsgi (pid=2576): Create > interpreter 'localhost|/query/servlet'. > [Wed Oct 31 00:50:42 2007] [info] mod_wsgi (pid=2576): Adding 'C:/ > Program Files/Apache/trunk/wsgi' to path. > [Wed Oct 31 00:50:42 2007] [info] [client 127.0.0.1] mod_wsgi > (pid=2576, process='', application='localhost|/query/servlet'): > Loading WSGI script 'C:/Program Files/Apache/trunk/wsgi/query.py'., > referer: http://localhost/query/query.htm > [Wed Oct 31 00:50:43 2007] [notice] Parent: child process exited with > status 3221225477 -- Restarting. > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Compiled for Python/2.5. > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Runtime using Python/ > 2.5.1. > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Python module path 'C:\ > \WINDOWS\\system32\\python25.zip;C:\\Program Files\\Python\\Lib;C:\ > \Program Files\\Python\\DLLs;C:\\Program Files\\Python\\Lib\\lib-tk;;C: > \\Program Files\\Apache\\bin'. > [Wed Oct 31 00:50:43 2007] [info] mod_wsgi: Initializing Python. > [Wed Oct 31 00:50:43 2007] [notice] Apache/2.2.6 (Win32) mod_wsgi/ > 2.0c1 Python/2.5.1 configured -- resuming normal operations > [Wed Oct 31 00:50:43 2007] [notice] Server built: Sep 5 2007 08:58:56 > [Wed Oct 31 00:50:43 2007] [notice] Parent: Created child process 3924 > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Compiled for Python/2.5. > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Runtime using Python/ > 2.5.1. > [Wed Oct 31 00:50:43 2007] [warn] mod_wsgi: Python module path 'C:\ > \WINDOWS\\system32\\python25.zip;C:\\Program Files\\Python\\Lib;C:\ > \Program Files\\Python\\DLLs;C:\\Program Files\\Python\\Lib\\lib-tk;;C: > \\Program Files\\Apache\\bin'. > [Wed Oct 31 00:50:43 2007] [info] mod_wsgi: Initializing Python. > [Wed Oct 31 00:50:43 2007] [notice] Child 3924: Child process is > running > [Wed Oct 31 00:50:43 2007] [info] Parent: Duplicating socket 188 and > sending it to child process 3924 > [Wed Oct 31 00:50:43 2007] [info] mod_wsgi (pid=3924): Attach > interpreter ''.
> ------ Whohoo :) -------
> [Wed Oct 31 00:50:43 2007] [info] mod_wsgi (pid=3924): Adding 'C:/ > Program Files/Apache/trunk/wsgi' to path.
> -------------------------
> [Wed Oct 31 00:50:43 2007] [notice] Child 3924: Acquired the start > mutex. > [Wed Oct 31 00:50:43 2007] [notice] Child 3924: Starting 250 worker > threads. > [Wed Oct 31 00:50:43 2007] [notice] Child 3924: Starting thread to > listen on port 80.
> It doesn't work for me anymore, and i don't see any error's in my log > file ?
Define doesn't work. What do you see from browser, a 500 page?
Can you add to your WSGI script file at start before anything else:
import sys print >> sys.stderr, 'module #1'
Does this appear in error logs? Sprinkle such debug at end of script file and also in the application function so can work out where execution gets to.
> Has it to do with the built notification ?
No.
You are using WSGIPythonPath. Can you comment that out and set sys.path in the WSGI script instead and see if it works. There may be an issue with WSGIPythonPath on Windows in this version.
|
