Re: wsgi servers...
Anything that claims any sort of support for WGSI 2 should be avoided as there is no such thing as WSGI 2, nor are there any blessed async extensions for WSGI. Graham On Dec 28, 6:16 am, dm73 miedema.do...@gmail.com wrote: May be marrow.server.http?https://github.com/marrow/marrow.server.http#readme The marrow.server.http package is a full-featured HTTP/1.1 compliant web server hosting WSGI 2 applications. It is: * Based on a modified version of Tornado’s IOLoop/IOStream architecture. * Faster than the competition by a significant margin. * Simple and efficient by design, allowing rapid development and easy bug fixing. (The protocol itself is only ~170 statements!) * Internally asynchronous. WSGI 2 applications will be able to benefit from this when wsgi.async is better defined. * Compatible with Python 2.6+ and 3.1+ out of the box; no need for automated conversion scripts or maintaining two separate code trees. * A fully unit tested protocol on both Python 2.6+ and 3.1+. (Excluding code specific to the other version.) On 24 dec, 21:05, Chris McDonough chr...@plope.com wrote: Does anyone know of a pure-Python WSGI server that: - Is distributed indepdently from a web framework or larger whole. - Runs on UNIX and Windows. - Runs on both Python 2 and Python 3. - Has good test coverage. - Is useful in production. - C -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: wsgi servers...
The CherryPy WSGI server is only one I would trust for both Python 2 and 3 at this point, but it is I believe still not installable as a separate package via PyPi, but only as part of CherryPy package as a whole. It can be extracted out of CherryPy and a copy used, but that sort of defeats the purpose. I recollect that progress is being made to some degree with gunicorn on Python 3 but don't know how far along. Graham On Dec 25, 11:05 am, Chris McDonough chr...@plope.com wrote: Does anyone know of a pure-Python WSGI server that: - Is distributed indepdently from a web framework or larger whole. - Runs on UNIX and Windows. - Runs on both Python 2 and Python 3. - Has good test coverage. - Is useful in production. - C -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Issue with mod_wsgi and repoze.what
What sort of auth? If you mean HTTP Basic authentication, read: http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms#HTTP_User_Authentication Graham On Monday, December 20, 2010 5:22:24 PM UTC+11, lollerskates wrote: I'm having a bizarre issue with mod_wsgi and repoze.what. My project pretty much works except for auth. I set it up with repoze.what.plugins.quickstart.setup_sql_auth (with sqlalchemy) and / login_handler calls when I try to login result in 404s. However, when I run it via paster and reverse proxy connections to it in httpd.conf, auth works fine. Any ideas? Thanks! -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: [modwsgi] apache2 lenny pylons mod_wsgi python 2.6 = error : Premature end of script headers: demo.wsgi, referer: http://example.com/
On 8 December 2010 20:37, Stéphane Klein steph...@harobed.org wrote:
Hi,
I use Pylons 1.0 Framework and mod_wsgi on production server.
I can use my application but randomly 1 request on 10 I've error :
Internal Server Error in browser and in error log file :
[client 82.231.115.1] Premature end of script headers: demo.wsgi, referer:
http://example.com/
Need to see the error messages before and after this and for matching
time in main Apache error log if you are using a virtual host specific
error log.
This message will arise in a few circumstances.
The first is that WSGI script file is being executed as a CGI script
for some reason.
The second is that the mod_wsgi daemon process is crashing.
The third is that daemon process is being forcibly restarted while
there are active requests which haven't responded in time.
I've read already many documentation page about this issue on mod_wsgi and
Pylons website.
Have you some idea about this error ?
More information about my configuration :
* I use apache2 from Debian package
* I've compiled Python 2.6 from source code
* I've compiled mod_wsgi-3.3 from source code (I've also tested with
mod_wsgi-2.8, same error)
VirtualHost *:80
ServerName example.com
IfModule mod_wsgi.c
WSGIScriptAlias / /home/examplecom/demo/demo.wsgi
WSGIDaemonProcess mydemo threads=1 maximum-requests=500
inactivity-timeout=500 processes=1 display-name=%{GROUP}
A very odd configuration.
You are running a single process with a single thread in it.
That it is a single thread only though, means that you can't be
incurring third possibility above though as a forced restart due to
maximum requests being reached as there can't be a concurrent request
that is being interrupted.
You can get a forced shutdown when request is still current due to
inactivity timeout if the request hangs for 500 seconds for your
configuration, but in that case I would say you would notice the hang
given that that is almost 10 minutes before that could kick in.
I would suggest so as to get more information if it is something
related to maximum requests or inactivity timeout, that you ensure
using:
LogLevel info
in Apache configuration and not the default:
LogLevel warn
Have a good look for segmentation fault messages in main Apache error
log as well.
Graham
WSGIProcessGroup mydemo
WSGIApplicationGroup %{GLOBAL}
/IfModule
ErrorLog /home/examplecom/demo/error.log
LogLevel info
/VirtualHost
Thanks for your help.
Regards,
Stephane
--
Stéphane Klein steph...@harobed.org - French
blog: http://stephane-klein.info
twitter: http://twitter.com/klein_stephane
pro: http://www.is-webdesign.com
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modw...@googlegroups.com.
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: apache2 lenny pylons mod_wsgi python 2.6 = error : Premature end of script headers: demo.wsgi, referer: http://example.com/
Logs show the segmentation faults I speak of: [Wed Dec 08 11:32:47 2010] [error] [client 82.231.115.1] Premature end of script headers: demo.wsgi, referer: http://example.com/employees/ [Wed Dec 08 11:32:47 2010] [notice] child pid 22620 exit signal Segmentation fault (11) Attach gdb to daemon process as described in: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB enter 'cont' command so runs again and then keep firing off requests until it crashes. Suggest removing maximum-requests during that time so that process isn't restarted because of that number being exceeded. In other words, debug why process is crashing. For ideas of why, see: http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions#Apache_Process_Crashes http://code.google.com/p/modwsgi/wiki/ApplicationIssues Graham On 8 December 2010 21:37, Stéphane Klein steph...@harobed.org wrote: Le 08/12/2010 11:21, Stéphane Klein a écrit : Le 08/12/2010 10:54, Graham Dumpleton a écrit : On 8 December 2010 20:37, Stéphane Kleinsteph...@harobed.org wrote: Hi, I use Pylons 1.0 Framework and mod_wsgi on production server. I can use my application but randomly 1 request on 10 I've error : Internal Server Error in browser and in error log file : [client 82.231.115.1] Premature end of script headers: demo.wsgi, referer: http://example.com/ Need to see the error messages before and after this and for matching time in main Apache error log if you are using a virtual host specific error log. This message will arise in a few circumstances. This is more information messages : http://pastebin.com/myi5D5Xn Well, I see the last message of this thread : http://groups.google.com/group/modwsgi/browse_thread/thread/ba82b2643564d2dd He say : Last night we installed mod_wsgi 3.3, and the KeyErrors have totally disappeared. I highly recommend the 3.3 upgrade if you're having this problem. Thanks, Graham. In my test, I've tested mod_wsgi 3.3 and 2.8 In last log message, it's 2.8 version. Now I've reinstalled 3.3 version, this is the new log messages : http://pastebin.com/kKztWiCY Regards, Stephane -- Stéphane Klein steph...@harobed.org - French blog: http://stephane-klein.info twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: apache2 lenny pylons mod_wsgi python 2.6 = error : Premature end of script headers: demo.wsgi, referer: http://example.com/
No clues unfortunately, just looks like arbitrary memory corruption. Do make sure you aren't loading mod_python into same Apache. Other than that, looks like a C extension module may be corrupting memory. What C extension modules for Python are you using? Graham On 8 December 2010 22:14, Stéphane Klein steph...@harobed.org wrote: Le 08/12/2010 11:52, Graham Dumpleton a écrit : Logs show the segmentation faults I speak of: [Wed Dec 08 11:32:47 2010] [error] [client 82.231.115.1] Premature end of script headers: demo.wsgi, referer: http://example.com/employees/ [Wed Dec 08 11:32:47 2010] [notice] child pid 22620 exit signal Segmentation fault (11) Attach gdb to daemon process as described in: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB enter 'cont' command so runs again and then keep firing off requests until it crashes. This is the debug message : http://pastebin.com/q9Lb72vQ Regards, Stephane -- Stéphane Klein steph...@harobed.org - French blog: http://stephane-klein.info twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: apache2 lenny pylons mod_wsgi python 2.6 = error : Premature end of script headers: demo.wsgi, referer: http://example.com/
On 9 December 2010 00:34, Stéphane Klein steph...@harobed.org wrote: Le 08/12/2010 12:20, Graham Dumpleton a écrit : No clues unfortunately, just looks like arbitrary memory corruption. Do make sure you aren't loading mod_python into same Apache. No, mod_python isn't installed. Other than that, looks like a C extension module may be corrupting memory. What C extension modules for Python are you using? this is more information about library loading found with gdb : http://pastebin.com/VFPe5BcK There are some clues in this log ? Only notable things are: Reading symbols from /usr/lib/libpq.so.5... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libpq.so.5 Reading symbols from /usr/lib/libmysqlclient_r.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libmysqlclient_r.so.15 Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsqlite3.so.0 Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxml2.so.2 These are preloaded by Apache or PHP extensions. If you are using any C extension module for Python which is expecting different versions of these libraries, you can end up with problems. If you can, don't load PHP into Apache and see if your problem goes away. Recommended that you don't use mod_php and mod_wsgi in same Apache if you can help it. Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Pylons repoze.bfg Merger - or - Where'd Pylons 2.0 go?
He would have meant . See: http://www.python.org/dev/peps/pep-/ On Nov 8, 9:07 am, Mike Orr sluggos...@gmail.com wrote: On Sun, Nov 7, 2010 at 1:27 PM, Ben Bangert b...@groovie.org wrote: On Nov 7, 2010, at 12:53 PM, Mike Orr wrote: So when that is approved, and has an implementation (which we'll try and help with as well), we absolutely plan on having a Python 3.x version. Having a larger development team now will definitely make it a lot easier. I'm sorry, I stand/sit corrected. Chris tells me PEP-333 is the current best choice. So I'm all on board for that, if it meets the needs. Chris McDonough mentions it was based on Web3 to an extent. Huh? PEP 333 is the original WSGI spec, which is still at 1.0 and still has its flaws. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: To pickle a controller function
On Aug 28, 5:13 am, Mike Orr sluggos...@gmail.com wrote:
On Fri, Aug 27, 2010 at 12:51 AM, waugust waugustyn...@gmail.com wrote:
Greetings,
Hoping someone will be able to shed some light here.
I'm building an application that requires to have something akin to
stored procedure calls on controller actions. Its to customize a
chain of actions in a sequence under determined variablesor
something like that (its late).
At any rate, my thought was to pickle a call to a controler with
app.get(url('path')) though I'm getting Can't pickle type
'function': attribute lookup __builtin__.function failed
What exactly are you pickling? Pylons, Paste, and literal() use
various lambdas and inner functions in their execution path. These are
unpicklable because Python stores the function by name, and it must be
defined at the top level of its module, not a dynamic function. Even
if you're not pickling a function directly, it's possible that it's
ultimately defined as a function somehow. We'd need to know the exact
thing you're pickling in order to confirm that.
So I saw this:http://code.google.com/p/modwsgi/wiki/IssuesWithPickleModule
So, that's no a viable means to my end, I suppose?
Maybe, but it would be somewhat complex to trace it. If you're running
the server with --reload, that may be the Script reloading case.
Butmod_wsgiis a unique environment, so I'm not sure the precise
conditions apply outside it. Unless this is happening undermod_wsgi?
Not sure why they are referencing that page on mod_wsgi wiki, but what
is described there is totally irrelevant to Pylons applications even
if running under mod_wsgi. The issues there are only relevant to stuff
defined in the WSGI script file itself and since for Pylons, and
pretty well all other Python web frameworks, the WSGI script file is
merely a place to adapt to the specific applications/frameworks method
of interfacing with a WSGI server, you would never have any
application code defined in the WSGI script file which would be
getting pickled by your application. The reason it is an issue for
stuff in WSGI script file is because the name given to the WSGI script
file when loaded in memory isn't the same as base name of file in disk
and nor is the directory the file is in in sys.path, so even if module
name matched file, still couldn't be found.
Graham
Basically what I wanted to do is have a Action model with a action
attribute to store a call to a controllers action in order to execute
on demand during a procedure later (and in steps), if that makes more
sense?
I guess I can't pickle controller actions?
Is there a better pattern
for something like this?
Mmm, yes, it kind of makes sense, but I'm not sure how to structure
it. There are two basic ways to freeze a function call so that it can
be called later. One is to store the name of the function and each
argument separately, and then look up the function by name and call it
with the args. The other way is to store the function-call string and
eval() it later. Eval() is generally undersirable because (1) it may
not be able to evaluate it if the runtime environment has changed;
e.g., if imports it depends on haven't been made, and (2) accidents or
malicious users could fashion the string to execute code you handn't
intended, and (3) Python can't optimize the local variables in any
function that contains eval(). But sometimes eval() is necessary, and
this may be a case.
Ultimately, what you'd want to save is the entire 'environ', because
any part of it may be relevant to the action or middleware. Are you
saving a real user request, or an artificial action call? An
artificial call is easier to recreate because you know which 'environ'
factors are relevant. For a real call, can't you just store the URL,
HTTP method, and request body? Then you could replay it at your
convenience.
Sorry if this is a bit vague, but the problem is a bit vague to me.
--
Mike Orr sluggos...@gmail.com
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 3:16 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote: My stack is nginx uwsgi pylons. I haven't heard of uWSGI before so I assume a lot of Pylons users haven't either. From the website (http://projects.unbit.it/uwsgi/) it looks like a mod_wsgi equivalent plus a lot of other stuff. It may appear to have a lot of stuff, but uWSGI is actually less capable than Apache/mod_wsgi in various ways. The difference is that Apache/mod_wsgi doesn't have a marketing page hyping what it does in the same way uWSGI does. :-( Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 3:48 am, weixi...@gmail.com weixi...@gmail.com wrote: I picked uwsgi b/c it seemed like potentially less overhead coupled with nginx, rather than nginx apache mod_wsgi. My reasoning was that the newer stable versions of nginx comes with uwsgi integration by default, you just need to install uwsgi to get started. I've not using supervisor but it's super easy to start the uwsgi daemon: uwsgi --uid www-data --paste config:/location/to/your/production.ini -- socket :8080 -d /var/log/uwsgi.log cd34 was the one that mentioned it and I was prompted to look into it. This article has benchmarks:http://nichol.as/benchmark-of-python-web-servers Just be aware that this benchmark used a flawed configuration for Apache/mod_wsgi. Specifically they setup Apache with 1000 threads in the process. One would never actually do this in practice. All they achieved by doing that was give the impression that Apache used a lot more memory that uWSGI. They would have likely got same performance results for Apache/mod_wsgi with just a handful of threads and if same number used as uWSGI was using, memory usage should have been quite comparable. Graham I used this article as a reference:http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/ It works just like mod_wsgi except a lot simpler as you don't need to apache config files. On Aug 10, 10:16 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Aug 10, 2010 at 2:42 AM, Weixi Yen weixi...@gmail.com wrote: My stack is nginx uwsgi pylons. I haven't heard of uWSGI before so I assume a lot of Pylons users haven't either. From the website (http://projects.unbit.it/uwsgi/) it looks like a mod_wsgi equivalent plus a lot of other stuff. Who here is using it and how do you like it? I run my apps under Supervisor with http proxy, mainly so that I can stop and restart them individually (supervisor restart app1). Does uWSGI allow this? -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 5:23 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com wrote: I picked uwsgi b/c it seemed like potentially less overhead coupled with nginx, rather than nginx apache mod_wsgi. My reasoning was that the newer stable versions of nginx comes with uwsgi integration by default, you just need to install uwsgi to get started. I've not using supervisor but it's super easy to start the uwsgi daemon: uwsgi --uid www-data --paste config:/location/to/your/production.ini -- socket :8080 -d /var/log/uwsgi.log So you have a separate uwsgi daemon for each application, Which you can also do with Apache/mod_wsgi. Graham rather than one for all the applications? In that case, the uwsgi command line itself could run under Supervisor. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 11:01 am, Weixi Yen weixi...@gmail.com wrote:
Thanks, turns out the SCRIPT_NAME /; is handled incorrectly.
Running liveheaders, it appears that when redirect_to is used, then the
request gets served ashttp://controller/actionwithout the domain.
I think it's appending / to another / to cause a double //
No idea of a workaround though =/
Not surprising really. This is because WSGI specification dictates
that SCRIPT_NAME shouldn't ever be ''/' by itself.
For URL against root of site, should be:
SCRIPT_NAME =
PATH_INFO = /
The PATH_INFO must always have a leading '/' and thus why for root of
site, SCRIPT_NAME would end up being empty.
So, try using:
uwsgi_param SCRIPT_NAME;
Graham
On Tue, Aug 10, 2010 at 3:26 PM, cd34 mcd...@gmail.com wrote:
uwsgi runs as a daemon, and nginx talks to it. uwsgi does some rather
aggressive caching which makes for a very fast pylons app.
If I recall, I had problems with versions newer than 0.9.4.4, but,
haven't tried any later releases. The command line I use is:
/usr/src/uwsgi-0.9.4.4/uwsgi -d /tmp/uwsgi.log --uid 1000 --gid 1000 -
s /tmp/uwsgi.sock -C -iH /var/www/facebook/ --paste config:/var/www/
facebook/fbapp/production.ini
And my application handles /
The question is, what is redirecting incorrectly?
I strip off /static/ and /fb/ and allow nginx to serve those:
location ^~ /static/ {
alias /var/www/xx.com/static/;
}
location ^~ /fb/ {
alias /var/www/xx.com/fb/;
}
location / {
uwsgi_pass unix:/tmp/uwsgi.sock;
include uwsgi_params;
}
and I believe I added:
uwsgi_param SCRIPT_NAME /;
in uwsgi_params.
http://cd34.com/blog/programming/python/pylons-and-facebook-applicati...
and
http://tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/
detail it a bit more.
I didn't have any problems using redirect_to which was used in a few
places. Based on your description, it is possible SCRIPT_NAME is
missing which would give you urls like:
http://domain.com/physical/disk/path/controller/action
If you can run something like livehttpheaders in firefox, or, even
something as basic as telnetting to nginx's port and doing a request
to see what the Location: header is, it might be a little easier to
troubleshoot it.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@go
oglegroups.com
.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 1:02 pm, Noah Gift noah.g...@gmail.com wrote: On Tue, Aug 10, 2010 at 4:49 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: On Aug 11, 5:23 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Aug 10, 2010 at 10:48 AM, weixi...@gmail.com weixi...@gmail.com wrote: I picked uwsgi b/c it seemed like potentially less overhead coupled with nginx, rather than nginx apache mod_wsgi. My reasoning was that the newer stable versions of nginx comes with uwsgi integration by default, you just need to install uwsgi to get started. I've not using supervisor but it's super easy to start the uwsgi daemon: uwsgi --uid www-data --paste config:/location/to/your/production.ini -- socket :8080 -d /var/log/uwsgi.log So you have a separate uwsgi daemon for each application, Which you can also do with Apache/mod_wsgi. I have used mod_wsgi with Apache a lot and I like it. On the other hand, nginx is a pretty cool web server. Any thought to combining efforts on making a unified module, that shares some of the same code, for both platforms? I could see situations where I would want to use Apache and other situations where I would want nginx. I think they are both good to have around. I have pondered that for mod_wsgid. That is mod_wsgi without embedded mode, but now having its own process manager (supervisor). Technically the daemon infrastructure, even though written against Apache runtime library could be used as back end to nginx in similar style to uWSGI, but retaining various features mod_wsgi has which uWSGI doesn't. I will not disagree that nginx from everything I know is better for static file handling, and also the behaviour of mod_proxy in nginx when used as a front end to Apache/mod_wsgi allows Apache to work more efficiently for dynamic web application with less resources than if no front end. Ie., due to nginx acting as network buffer and isolating Apache from slow clients. This model of nginx proxying to Apache/mod_wsgi does as some point out though mean having to manage multiple servers, so the daemon infrastructure of mod_wsgi directly behind nginx is attractive, presuming that mod_proxy's good qualities in nginx can be harnessed in that arrangement as well. Why am I not doing this though. The prime reason is lack of time. When I can find myself a better job, maybe I'll get that opportunity time wise to pursue it. This does though presume I can get the motivation up as well. The joke used to be that every man and his dog was writing a Python web framework, now it is that every man and his dog is writing a WSGI hosting mechanism. With the rash of options around, one has to question whether yet another variation is going to be accepted or not. A further issue is trying to support multiple servers. Right now I am happy with supporting just Apache because it means I can do a top class job with it and ensure that it works perfectly. When you support multiple servers, you have to spread your time more across all the options and quality potentially drops. This may be fine for the uWSGI folks who get to do the work as part of their paid day job and have customers potentially paying them for support as well, but I don't have that luxury. All the same, would be interested to here if people think that supporting other servers would be good, or whether felt that uWSGI, and Phusion Passenger, is already satisfying that space now and so no point. Graham rather than one for all the applications? In that case, the uwsgi command line itself could run under Supervisor. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- Thanks, Noah -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: uwsgi
On Aug 11, 1:45 pm, Mike Orr sluggos...@gmail.com wrote: So, how again do you test a uwsgi-daemon I believe uWSGI supplies a Python module which can talk its native daemon protocol. They use this to allow systems like Twisted to talk to it I think. See: http://projects.unbit.it/uwsgi/wiki/RunOnTwisted or mod_wsgi daemon site? In all the time that Apache/mod_wsgi has been around, there hasn't been any situation where having the ability to communicate direct to the daemon process, bypassing Apache server processes, would have been useful. Looking at the final WSGI environment dictionary passed to the WSGI application has always been enough. This is because the tight integration means that the WSGI environment is always being setup correctly and you don't get the problems with FASTCGI and HTTP proxies where the intermediary can subtly change things on the way through. Allowing direct access to the daemon process would also break down the security of the system if used on a shared hosting system and leave it open to attack due to way mod_wsgi works. The only time this issue ever comes up is where people try and push the line that mod_wsgi daemon mode is evil in some way because it uses what they see as a proprietary protocol rather than FASTCGI or HTTP. In practice it is never an issue. With PasteHTTPServer I can just fire up a text browser and send it an HTTP request. Just like you can with Apache/mod_wsgi. ;-) But what's kind of client can form a uWSGI or SCGI request? At this point am not sure what you are talking about since you are saying SCGI where as before you said mod_wsgi. I'll keep commenting in respect of mod_wsgi anyway. It's not rare that I upgrade an app and restart it and it refuses to start and Apache won't tell me why, the Supervisor log is empty and there's nothing useful in the app error log. Which has nothing to do with what protocol is used across the socket between web server front end and daemon processes. For Apache/mod_wsgi, where stuff doesn't appear in the Apache error logs, it is usually because the WSGI application itself is capturing the exception and discarding it. Django in non debug mode is a classic case. You can only get the error messages if you set up a middleware to catch it and email it to you or explicitly log it. The only other cases are where the process outright crashes, but even then you still at least get a message saying that a segmentation fault occurred and if you up debug level to info in Apache you will get various other messages indicating processes died and restarted as well. Most people never read the mod_wsgi documentation on debugging and learn however that debug output can be increased. The default is not to be noisy else it fills up the Apache error logs. Finally, there was a bug which in certain virtual host configurations would cause logging from a SSL virtual host to go missing, but that has been fixed now. Graham Sometimes I can run it in development mode and see what the problem is, but other times it needs the exact production environment; e.g., for a permission error where my account can write a file but the www-data can't, or where it can't open a log file because the directory containing it doesn't exist. So a command-line client or browser plugin that can take a URL and send a uWSGI or SCGI request would seem like a vital tool for troubleshooting such installations, yet it doesn't seem to exist. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: mod_wsgi and DistributionNotFound exceptions
On Jun 29, 5:02 pm, cd34 mcd...@gmail.com wrote:
What are the contents of your .wsgi script?
#!/usr/bin/python
import os
import sys
import site
sys.path.append('/var/www/pylons/cp')
site.addsitedir('/var/www/pylons/lib/python2.5/site-packages')
os.environ['PYTHON_EGG_CACHE'] = '/var/www/pylons/eggcache'
from paste.deploy import loadapp
application = loadapp('config:/var/www/pylons/cp/development.ini')
And make sure that /var/www/pylons/eggcache is writeable by your
webserver.
There are probably some issues with the particular script and perhaps
Graham Dumpleton will drop by and correct it, but, this is the bare
minimum wsgi script that worked for me.
wsgi doesn't use portions of the development.ini that don't apply to
it and you don't need to run your project as an egg. Development
under apache2/mod_wsgi is a little tricky.
http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons
And also read:
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
I believe the DistributionNotFound issue has come up before a couple
of times.
In one instance the Python that mod_wsgi was using wasn't the same as
the virtual environment was using or something similar.
I also vaguely recollect there being some issue with a specific
version of setuptools, but I could be dreaming about that.
The WSGI script file is definitely needed, as well as confirmation as
to what version of Python was built for and is using and which Python
was used to construct any virtual environment.
Graham
There is a page somewhere that details what it takes to allow you to
leave debug=true in your development.ini when running under embedded
mode, but, I don't have it bookmarked and can't find it on the wiki.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: embedding pylons in apache problem
On May 14, 10:16 am, James McManus jmpmcma...@gmail.com wrote: I'm trying to embed pylons in my apache server, following the instructions in the Pylons Book. When I start my server I do not get an error. The following egg is created in egg-cache: egg-cache/simplejson-2.0.9-py2.5-linux-x86_64.egg-tmp/ However, when I access the web site, I get the following error: [Thu May 13 20:02:32 2010] [error] [client 71.120.222.68] Error - type 'exceptions.OSError': [Errno 13] Permission denied: '/html' I set the permission on /html, which is my application directory, to the same setting I have for egg-cache, so I should be able to write to it, since I was able to write to egg-cache. What is pylons writing to my applications directory, and do I need to have another setting to write to that directory? You cant use relative pathnames, use absolute paths instead. See: http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Working_Directory Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: application deployment question about nginx and pylons
On May 7, 2:06 am, Jonathan Vanasco jonat...@findmeon.com wrote: I'm of this school of thought: if you're doing anything with moderate to high traffic, you should be running NGINX on port 80 , with a proxypass to something else. What you proxypass to, however, is up to you. 1- paster 2- wsgi 3- apache the important thing is to get Apache off of port 80 , its really just not a great performer. you *especially* don't want to run apache on port 80 if you're using a single apache configuration. the mod_perl folks did the math and wrote a chapter or two about it, which may have wound up online... it was called vanilla apache + mod perl or something like that. Comparing to mod_perl is not a good idea as they only support embedding. That is, the Perl application resides in the actual Apache server child processes. Thus the excessive requirements of a fat Perl application affected overall Apache memory usage and performance. The same is the case for mod_python and embedded mode of mod_wsgi. You can see how some of this plays out for Python in: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html If you use daemon mode of mod_wsgi, which uses distinct processes like fastcgi/scgi/ajp solutions, you avoid those issues. So, as long as you ensure out of process solution used such as mod_wsgi daemon mode, fastcgi or scgi etc, Apache as front end is going to be more than adequate for the majority of people. Even so, still agree that nginx front end does bring some benefits in respect to static file serving and isolation of Apache from slow clients, thereby allowing Apache to perform better with less resources than would be required if used as front end. Graham you basically want the lightest and leanest server running on port 80 as possible (nginx, or a stripped down apache with as few DSOs loaded as possible) . you can then proxy back to other servers as needed. if you decided to stay apache, you DEFINITELY want to run a vanilla instance on port80 to handle static files and proxy back. the reasons for this are twofold: 1- IIRC, a stripped down apache process is 500k or so of memory; a mod_* will grow to 3-5MB, and then compile in your application code and allocated/reserved memory... which often ends up at 20-30MB per process. if you run your app on port 80, both static files and dynamic content will be served by these apache processes - which means you'll tie up the 20-30mb processes with tasks a 500k one could do. if you profile your app correctly, you can find the right types of servers to run that will easily allow you to increase your throughput by 10-20x -- if not more -- just by smarter resource allocation. 2- if a client is slow, or drops a connection without being detected, your dynamic apache ( or anything else ) just sits there slwly serving a file until a timeout is reached. if you put a 'vanilla' server on port 80, the dynamic server instantly returns the result to it... and it can handle the timeout/slowdown issues... freeing up the memory and processor for the dynamic server to process another request. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: undefined error with mod_python
On Apr 26, 7:01 pm, Tim-Erwin p...@tim-erwin.de wrote: Thanks cd34 for your ideas. I use mod_python for other stuff on my server, but that doesn't prevent me from also using mod_wsgi. Especially, as it is already very well supported across python applications and is said to perform better than mod_python. Nonetheless, using mod_wsgi didn't help, I only got 500 codes. No error output in any log file although I even get info messages. I tested on a different system (should have done that much earlier), there I got error output and found, it's the EvalException middleware which I forgot to disable with [DEFAULT] debug = false That's it. Haven't tested with mod_python any more, but it works well with mod_wsgi. Does anybody have any further idea why I don't get error output on my production system? Possibly because Paste server does special configuration of logging module which isn't done if one uses loadapp() by itself to generate a WSGI application entry point. See: http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi So, if you aren't already, introduce the fileConfig() call as described along with appropriate .ini file entries. Graham Thanks again Tim On 25 Apr., 02:29, cd34 mcd...@gmail.com wrote: LogLevel error or, at worst: LogLevel debug in your apache config might produce more results in your error logs. Your config looks right, but, the error logs are probably set to crit which is why you're not seeing anything of value in the logs. Remember you can also specify an ErrorLog directive in your virtualhost to cut down on messages. If you are not using mod_python for anything else on the server, you might also considerhttp://code.google.com/p/modwsgi/ -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Pylons hosting on a VPS (memory usage)
On Apr 21, 7:57 pm, cropr ruben.dec...@gmail.com wrote: I am running 3 pylons apps on a single VPS with 256 MB ram (no swap space). I am using apache in multi threaded mode and mod_wsgi. Every 2 to 3 months I restart the apache server, because the apache child processes gradually grow in memory size, reaching slowly the 256 MB limit on busy days. You are presumably using daemon mode of mod_wsgi else this wouldn't even likely be possible. Anyway, read 'http://blog.dscpl.com.au/2009/11/save-on-memory-with- modwsgi-30.html'. It explains how to counter the leaks in Python which occur on an Apache restart. Graham Ruben On 20 apr, 00:28, Alex a...@oxygencomputers.co.uk wrote: Hi all, Does anyone have any advice on hosting multiple Pylons apps in a low memory environment like a VPS. I've written a few apps using Pylons and it's great, so I'd like to use it for more. However the stuff I've used it for so far has justified running the apps on servers of their own, so I've been running them using paste behind lighty. However this seems to need quite a bit of RAM. I'd like to be able to host quite a few low traffic volume apps on the same VPS, but it seems that running several paste instances wouldn't be possible in the same way it's possible to host lots of low traffic PHP apps behind Apache and mod_php. Anyone have any advice on deployment? TIA. Alex -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: How do you signal the end of streaming content?
On Apr 21, 9:31 am, jazg tazg2...@gmail.com wrote: In particular, I want to trigger a long process by going to a page, without having to wait for the process to finish. I thought I could do this: def page(self): def stream(): yield content long_process() return stream() But it doesn't exactly work. IE doesn't show content until after long_process finishes. Firefox shows it, but continues to show Transferring data. I tried response.content_type = len(content) but it doesn't seem to have any effect. What else can I do? Have a read of: http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode It may be in the mod_wsgi documentation, but that WSGI mechanism of using close() on returned iterable should would for any WSGI hosting mechanism. Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pylons cookbook startup script/activate_workingenv
On 28 March 2010 04:32, Mike Orr sluggos...@gmail.com wrote: If you have a *.wsgi file, you must be using mod_wsgi. I don't know that configuration but here's the official documentation, found by googling pylons mod_wsgi: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons See: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments In general, to use a virtualenv, you run the python or paster or whatever in the 'bin' directory of the virtualenv. Or you activate it on Unix/Mac by running source myvirtualenv/bin/activate or on Windows by running myvirtualenv/Scripts/activate.bat. Activating shifts your $PATH around to put the virtualenv at the beginning of it. Or you install virtualenvwrapper and run workon myvirtualenv. (That's my preferred way.) But mod_wsgi is different. The virtualenv has an activate_this script that was originally intended for situations like mod_wsgi, but I think the mod_wsgi author has said not to use it. I may be wrong about that. I've cc'd Graham Dumpleton for clarification. I discourage use of activate_this as it changes sys.prefix during execution of process. This may be totally resasonable if your application is only thing running within an interpreter, but mod_wsgi allows multiple applications to run within same interpreter without them being managed under a single entry point. One can only speculate what changing sys.prefix in the middle of the execution of code running in other threads will do. Even using site.addsitedir() and reordering sys.path is probably not a good idea to be done explicitly in WSGI script file as the documented examples show as in a multithreaded system, two separate WSGI applications could do same thing at same time and muck each over up. The preferred method is therefore WSGIPythonPath if using mod_wsgi embedded mode and python-path if using daemon mode. These methods ensure that the fixups are done while still only a single thread running and before any user code is actually run, thereby avoiding multithreading issues and issues with changing sys.prefix. Graham The IntegrationWithPylons article has a link to mod_wsgi and workingenv.py. I think the latter page should be deleted and mod_wsgi instructions put into the Pylons docs. Any objections to deleting it now? On Sat, Mar 27, 2010 at 6:35 AM, mitochromium th...@thoughtboard.com wrote: OK thanks. Is the setup similar, though? i.e. creating a .wsgi file and pointing it to the virtualenv? I can't seem to find any docs on setting up virtualenv, just installation. On Mar 27, 3:12 am, Mike Orr sluggos...@gmail.com wrote: On Fri, Mar 26, 2010 at 9:54 PM, mitochromium ajfar...@gmail.com wrote: I'm running through the cookbook, and have been stumped by the startup script/activate_workingenv.py section. I'm assuming (it's not really clear) that I'm supposed to replace the .wsgi file contents with the startup script, which I did. I then added activate_workingenv.py to my site-packages. It seems to be behaving strangely, though. Upon restarting apache and visiting the page, I get a 500 error. apache error_log states : IOError: [Errno 2] No such file or directory: '/home/test/./lib/python2.5/setuptools.pth' It seems to be concatenating with the . no matter what, or if I omit the period, strips root from string. e.g. If I edit activate_workingenv.py to something like: package_root = os.path.join(root, '/lib/python' + python_version) error_log will state: IOError: [Errno 2] No such file or directory: '/lib/python2.5/setuptools.pth' omitting WORKING_ENV/root from the string. Workingenv is old and no longer supported. Virtualenv has superceded it. The recipe you're looking at may be obsolete. -- Mike Orr sluggos...@gmail.com -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: [pypefitters discussion] Re: WSGI at PyCon
On 20 February 2010 15:53, Mike Orr sluggos...@gmail.com wrote: - ``mod_wsgi`` has, and ``CherryPy`` will have, options to handle the headers in multiple ways (bytestrings vs Unicode), so that they'll work with whatever the final spec is (or whatever the user wants). No, mod_wsgi 3.X does not have any options to override the encoding or whether bytes is used. Some of the release candidates did, but the options were taken out and it only implements the defacto WSGI on Python 3.0 interpretation the same as wsgiref attempts to implement. Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: HEAD requests
You may find my blog post about GET/HEAD and WSGI interesting.
http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html
Because of Python web frameworks doing all sort of odd things and not
always handling HEAD properly, I in part felt that WSGI adapters
should always just convert HEAD to GET as is safest thing to do to
ensure correct behaviour.
Graham
On Feb 3, 9:35 pm, Mike Burrows m...@asplake.co.uk wrote:
When routes have conditions that constrain the request method to GET,
any HEAD requests result in 405 Method Not Allowed. Bug or feature?
With HEAD added as an allowed method, the server (paster) does the
right thing and returns a zero-length body.
Working around this in one's routing isn't always an easy option -
mapper.resource() or mapper.collection() don't add HEAD automatically,
and they probably shouldn't either. Can't help thinking that somewhere
in the middleware stack (before Routes I guess) a HEAD should be
turned temporarily into GET so that HEAD is allowed everywhere GET
is. As such this feels to me a Pylons issue. Before I raise a
ticket, any thoughts?
Small asides:
(1) I haven't tested what happens if you use @restrict instead (I
don't use it)
(2) a head() method in paste.fixture would be nice, but in the
meantime app._gen_request('HEAD', ...) does the job. Tried real http
requests using curl too.
Regards,
Mike
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: prefixmiddleware behind proxy generates correct h.url's, but redirect's dont keep 'https'
On Feb 2, 12:30 am, Damian damiandimm...@gmail.com wrote: Hi, Just in case anyone else runs into this, the proxy must forward the variable X_FORWARDED_PROTO, and not, as a few other posts i found suggest: X_FORWARDED_PROTOCOL. So for nginx use in your location section where you are proxying: proxy_set_header X_FORWARDED_PROTO $scheme; Technically you would use 'X-Forwarded-Proto' which is the normal convention for case on HTTP headers. This will be automatically converted to HTTP_X_FORWARDED_PROTO by web server/WSGI adapter on backend. Graham Cheers, Damian On Jan 29, 5:28 pm, Damian damiandimm...@gmail.com wrote: Hi, I'm just moving my webapp which runs in apache/mod_wsgi behind an nginx proxy. I've set it up to use the prefixmiddleware and all the https url_for'ed url's generate as expected. Unfortunately this doesn't seem to be the case for redirect_to urls, as these send me to the http, not the https url.. Am I missing something? Cheers, Damian -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Fastcgi and performance
On Jan 31, 4:46 am, PF4Pylons ultimulunic...@gmail.com wrote:
Hi guys
Here is what I have manged to get working:
=HelloWorld.fcgiworking, OK
#!$HOME/html/Others/PVE/bin/python
import sys
sys.path.insert(0, '$HOME/html/Others/PVE/lib/python2.5')
You cannot use '$HOME' in Python variable strings like that. List the
path explicitly.
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
If this work when you had $HOME above, they must already have flup
installed.
==
=HelloWorld.cgiworking, OK=
#!$HOME/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
sys.path = ['$HOME/html/Others/HelloWorld'] + sys.path
wsgi_app = loadapp('config:$HOME/html/Others/HelloWorld/
development.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
=MyApp.cgiworking, with errors, see
below=
#!$HOME/html/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
#os.chdir($HOME/html/Others/Anki/MyAppweb)
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
production.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/css/app.css
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/study/getCSS
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery-1.2.6.min.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery.hotkeys-0.7.8-packed.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:07 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/activity.gif
These files are all rooted in the public folder of the application.
How can I fix this please?
However the my application is slow, so is the HelloWorld aplication
athough this one has no errors in the log.
I believe this is because of the cgi approach.
==Myapp.fcgi ==Lightning fast===BUT WITH ERRORS see
below=
#!/home/content/c/r/i/cristip/html/Others/PVE/bin/python
import os, sys
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
from paste.deploy import loadapp
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
development.ini')
# Deploy it using FastCGI
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app).run()
The problems that I have with FCGI
On top of the errors listed above (the app is not able to find
javascript files, css files and gif files I also have
the following problem:
The address of the application is:
http://www.mydomain.com/cgi/MyApp.fcgi/ (doesn't work without / at
the end, I found that out accidentally)
You need some mod_rewrite magic, but they have to have
allowed .htaccess file usage and required overrides to allow you to
use mod_rewrite directives.
Do you have that access?
Graham
The application has some menus which are all pointed to a shortest
path, see below:
Login should be
http://www.mydomain.com/cgi/MyApp.fcgi/account/login
but the application is pointing to
http://www.mydomain.com/cgi/account/login
ans so on. As you can see MyApp.fcgi seems to be eliminated
automatically and I believe that is because the application
was not designed to work this way. How can I fix this?
Thank you all
PF
On Jan 28, 11:28 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Jan 29, 2:02 pm, PF4Pylons ultimulunic...@gmail.com wrote:
The provider is Godaddy
Here is all they say about fastcgi in their help section
http://help.godaddy.com/search?q=fastcgix=0y=0
Quite cryptic sometimes.
I will get back to this after I configure the HelloWorld app.
I did mention the provider in the other thread I started here, I had
the impression you replied there too.
I will also update that thread, I have made some progress there but I
run into an other roadblock.
Under their Perl FAQ entry they say:
NOTE: This will need
Re: Fastcgi and performance
On Jan 29, 2:02 pm, PF4Pylons ultimulunic...@gmail.com wrote:
The provider is Godaddy
Here is all they say about fastcgi in their help section
http://help.godaddy.com/search?q=fastcgix=0y=0
Quite cryptic sometimes.
I will get back to this after I configure the HelloWorld app.
I did mention the provider in the other thread I started here, I had
the impression you replied there too.
I will also update that thread, I have made some progress there but I
run into an other roadblock.
Under their Perl FAQ entry they say:
NOTE: This will need to be done in any directory outside of /cgi in
which you want to run .fcgi scripts.
So, they mention .fcgi files.
It would be quite silly if they were using .fcgi files and the only
thing you can stick in it is Perl. If that were the case they should
have used a specific Perl extension.
As such, it looks a good bet that if you can get flup installed into
your account and can set up sys.path to reference where flup is, it
may work.
Thus, install flup under lib/python in your home directory. Presuming
your home directory is '/home/pf4pylons', then use following in file
called 'hello.fcgi'.
#!/usr/bin/env python
import sys
sys.path.insert(0, '/home/pf4pylons/lib/python')
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
Get that going and then you can work out getting Pylons installed as
well.
Graham
Thanks
PF
On Jan 28, 9:57 pm, PF4Pylons ultimulunic...@gmail.com wrote:
010/1/29 PF4Pylons ultimulunic...@gmail.com:
Hi Graham
According with the
documentationhttp://www.fastcgi.com/docs/faq.html#typical_httpd.conf
they can configure some specific file extensions only to be executed
via the fastcgi module.
http://www.fastcgi.com/docs/faq.html#typical_httpd.conf
No, as I understand the configuration in that specific section, that
does not restrict it to a specific language. This is because that
configuration would rely on the #! line in the .fcgi file to know what
interpreter to run.
If you look down further at the PHP example however, that does
restrict the language. This is because for .php it has been configured
to execute a wrapper or helper script instead of the target resource.
That wrapper will then read in the resource file and interpret it
specifically as PHP code, ignoring the #! line.
As the web hosting company mentioned in their documentation they only
support perl and ruby for
fastcgi. They don't mention any extension to be specifically used for
fastcgi.
In general if, according with the documentation you specify fcgi or
fpl as extesions these will be executed via
fastcgi. Does the fastcgi module care for the shebang line you put in
your file? Can that be restricted only to
specific script interpreters?
As I said before, it really depends on how the hosting company has
configured it. The default way people usually set up fastcgi however,
ie., that typical configuration, would be such that .fcgi would be
executed per the #! line.
I am thinking about just pointing the shebang line to Python but
use .pl extension for my files. Would that work?
Try it. You haven't as far as I remember even pointed at which hosting
company it is or where there documentation is describing their setup,
so I am not going to know. Just try and make sure you have a working
Python fastcgi hello world first by testing it on your own computer
system somehow because any mistake in the code will yield a 500 error
and you may not know whether it is a coding error in your program or
lack of flup, of whether it just isn't honouring the #! line.
Graham
On Jan 26, 10:48 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: Fastcgi and performance
On Jan 27, 1:56 pm, PF4Pylons ultimulunic...@gmail.com wrote: Hi guys Thanks for your replies. Godaddy doesn't support mod_wsgi and they support FastCGI only for Perl and Ruby. There is nothing special that has to be done to FASTCGI setup to support a particular language. If they already have Python installed for CGI scripts, you should be able to use it with FASTCGI. The only dependency is that you may have to install flup into an area in your own account and use it from there instead of it being installed in main Python installation. In worst case you could even install your own Python installation so you can use any version you want instead of any antiquated version they supply. That they say they don't support Python either means they just don't want anyone running Python at all, or they don't understand how FASTCGI works which leaves the question of why you would want to use them if their technical knowledge is so limited. As such, you may want to go find a web host that actually knows about Python and how to host web applications using Python properly. That company doesn't seem to be a very good choice. Graham I just opened a ticket a support ticket with them to verify if the ProxyPass which I understand is the same with Reverse Proxy is allowed and installed. What other options do I have? For various reasons I can't change the provider. Thank you PF -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Can't get pylons to log in mod_python mode..
Paste server does special stuff to initialise the environment for
logging. Arguably it shouldn't do this and any such initialisation
should be a side effect of getting the root WSGI application object.
What it means is that you have to perform the same initialisation
somehow when using mod_python.
For discussion of how to do that for mod_wsgi see:
http://groups.google.com/group/pylons-discuss/browse_thread/thread/9b9add4529b3779c
You will have to work out how to do the same for mod_python.
Graham
On Dec 9, 7:20 am, D D d2n...@gmail.com wrote:
Hi,
I have a pylons app, and everything works fine with running via Paster
serve.
However, I have deployed it using mod_python, and I am not able to get it to
print any logs anywhere.
I don't get any logs in chainsaw, console (apache's error_log) or in the
specified log file (/var/log/mysite.log). This only happens when I run it
via mod_python, everything works fine while running through paster serve.
I do get exceptions in apache error_log when there is an exception/crash for
the site.
Below are the relevant parts for logging:
# Logging configuration
[loggers]
keys = root, routes, mysite, sqlalchemy, mako, secure
[handlers]
keys = console, chainsaw, mysitelog
[formatters]
keys = generic, xmllayout
[logger_root]
level = DEBUG
handlers = console, chainsaw, mysitelog
[logger_routes]
level = INFO
handlers =
qualname = routes.middleware
[logger_mysite]
level = DEBUG
handlers =
qualname = mysite
[logger_sqlalchemy]
level = DEBUG
handlers =
qualname = sqlalchemy.engine
[logger_mako]
level = DEBUG
handlers =
qualname = pylons.templating
[logger_secure]
level = DEBUG
handlers =
qualname = pylons.decorators.secure
[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic
[handler_chainsaw]
class = xmllayout.RawSocketHandler
args = ('localhost', 4445)
level = NOTSET
formatter = xmllayout
[handler_mysitelog]
class = FileHandler
args = ('/var/log/mysite.log','a')
level = DEBUG
formatter = generic
[formatter_generic]
format = %(asctime)s,%(msecs)03d %(levelname)-5.5s [%(name)s] %(message)s
datefmt = %H:%M:%S
[formatter_xmllayout]
class = xmllayout.XMLLayout
Any suggestions on where to start debugging this? I am generally pretty new
to mod_python, so any pointers will help.
Thanks,
DD.
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Re: slow import
On Dec 7, 3:07 am, andres and...@octopart.com wrote: Hi, I've been looking into performance bottlenecks in my pylons app and I noticed that importing the pylons module itself takes 150 msec. It might seem pedantic to be worried about 150 msec, but it seems like an unnecessary startup cost. Have you guys considered ways of making pylons modules faster to import? Certain modules in Python standard library themselves are slow to import. Thus, not necessarily a Pylons issue. Start out by seeing how long it takes to import 'cgi' module to begin with and you may see what I mean. import time def func(): ... a = time.time() ... import cgi ... print time.time() -a ... func() 0.0814950466156 So, that is 80ms alone on my couple of year old iMac. Graham -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: DistributionNotFound problem
On Aug 28, 1:33 pm, anuraguni...@yahoo.com anuraguni...@yahoo.com wrote: Thanks for the answers, i have found the problem Problem was with mod_wsgi, somehow it is using old python installation (python 2.4) and i have installed packages on python2.5, which is in system path too. Apache/mod_wsgi is compiled against a specific version of Python. If you need to use a different version of Python, you will need to either install binary version of mod_wsgi compiled against desired version, or build it from source code yourself. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons marketing, ( new thread from web tech )
On Aug 22, 2:48 pm, Didip Kerabat did...@gmail.com wrote: From my experience both are not ridiculously hard to deploy. Even though pylons have more options. It's a hard sell on that one, i think. On the other hand, isn't django having problem with wsgi? Care to elaborate on what supposed problems Django has with WSGI rather than leaving a cloud of doubt with no explanation? FWIW, hosting Pylons on anything besides Paste HTTP server can also be a problem in some cases. This is because certain setup steps for logging expected by Pylons applications are embedded in Paste HTTP server where they should not really be. This means that those magic steps have to be some how duplicated when using alternate WSGI hosting mechanisms. Such steps aren't though even documented in Pylons documentation, unless that has changed since last time I looked. So, in that respect, as a self contained WSGI application/component, Pylons isn't actually a good WSGI citizen. Part of the problem here is that there is no standardised model for deployment of WSGI applications. WSGI defines the interface, but doesn't cover the deployment of that in a standard way such that there is one story for all hosting solutions. As a consequence, all Python web applications using WSGI to adapt to the underlying web server have their own caveats and extra things you need to do. Things can get worse again when you are trying to plug a WSGI application as a component into another application structure. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons marketing, ( new thread from web tech )
On Aug 23, 9:56 am, Philip Jenvey pjen...@underboss.org wrote: On Aug 22, 2009, at 3:36 PM, Graham Dumpleton wrote: FWIW, hosting Pylons on anything besides Paste HTTP server can also be a problem in some cases. This is because certain setup steps for logging expected by Pylons applications are embedded in Paste HTTP server where they should not really be. This means that those magic steps have to be some how duplicated when using alternate WSGI hosting mechanisms. Such steps aren't though even documented in Pylons documentation, unless that has changed since last time I looked. logging is setup by PasteDeploy's loadapp, not the Paste HTTP server itself. Pylons apps are always created via loadapp for any kind of deployment, so that's the appropriate place. Is the following logging to wsgi.errors documentation not enough in this regard?http://pylonshq.com/docs/en/0.9.7/logging/#logging-to-wsgi-errors If that is the case and everything is done and self contained within loadapp(), why is it necessary to call paste.script.util.logging_config.fileConfig() explictly for alternate hosting mechanisms, as documented in: http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi prior to calling loadapp(). Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons marketing, ( new thread from web tech )
On Aug 23, 9:34 am, Mike Orr sluggos...@gmail.com wrote: On Sat, Aug 22, 2009 at 3:36 PM, Graham Dumpletongraham.dumple...@gmail.com wrote: On Aug 22, 2:48 pm, Didip Kerabat did...@gmail.com wrote: From my experience both are not ridiculously hard to deploy. Even though pylons have more options. It's a hard sell on that one, i think. On the other hand, isn't django having problem with wsgi? Care to elaborate on what supposed problems Django has with WSGI rather than leaving a cloud of doubt with no explanation? Django was made before WSGI and has had some trouble adapting to it. Using Django in a WSGI environment has required some significant hacking, The only real problem was that they didn't honour SCRIPT_NAME as mount point. That was fixed back before 1.0 came out. and it seems that resolving these issues has not been a high priority for them because their native servers work just fine thank you. There native server is a development server and they stress that it is not for production sites. Thus they are dependent on other hosting mechanisms and it is stretching it a bit to suggest that they don't do stuff because their native server works fine. You can't even say that they delayed doing things because mod_python support worked fine because that was broken as well for mounting at a sub URL and still requires a hack by virtue of user having to duplicate that information through a configuration option. That there is an issue with that is mod_python's fault though and not Django. It comes out of their different philosophy. Django users/developers are happy if it works in its own separate world. Pylons/WSGI enthusiasts are obsessed with interoperability The only thing I can see that anyone could draw an issue with here is that they have their own middleware interface and don't use WSGI internally. Irrespective of the fact that Django existed before WSGI, doing it that was is really a design decision and if someone wrote a Python web framework now they could make the same decision to ignore WSGI for internal interfaces. Part of the discussions going around about WSGI is not to use WSGI for that internal interface because of WSGI being inadequate for it to a degree. So, that they are a monolithic application and have their own middleware system for bringing components together is hardly a point to be criticised on. It is a valid alternate way of doing things and will be attractive to some users over a more loosely coupled componentised type system. FWIW, hosting Pylons on anything besides Paste HTTP server can also be a problem in some cases. This is because certain setup steps for logging expected by Pylons applications are embedded in Paste HTTP server where they should not really be. This means that those magic steps have to be some how duplicated when using alternate WSGI hosting mechanisms. Such steps aren't though even documented in Pylons documentation, unless that has changed since last time I looked. So, in that respect, as a self contained WSGI application/component, Pylons isn't actually a good WSGI citizen. The logging setup needs some improvement but that's not a WSGI issue. WSGI doesn't address logging. I'll address the technical problem in another thread. But it is a deployment issue. I am not suggesting here that these things should be a part of WSGI but a separate abstraction is needed to encompass them to make hosting easier through single recipe that works everywhere, unlike now where users have to work out how to customise it, but where many packages don't make it easy to deploy on anything but their favoured hosting mechanism, mainly because of lack of documentation on what is required. Part of the problem here is that there is no standardised model for deployment of WSGI applications. WSGI defines the interface, but doesn't cover the deployment of that in a standard way such that there is one story for all hosting solutions. As a consequence, all Python web applications using WSGI to adapt to the underlying web server have their own caveats and extra things you need to do. Things can get worse again when you are trying to plug a WSGI application as a component into another application structure. WSGI has grown way beyond its original scope. And nobody knew what issues would arise with mod_wsgi because it didn't exist. I don't see how you can get around the fact that every web server or Apache module is unique. Not to mention every daemon manager on every platform. WSGI is just a Python protocol; it doesn't address those issues. I wasn't thinking specifically about mod_wsgi when making these comments but any hosting mechanism. Yes hosting mechanisms may be unique, but there is nothing to stop a higher level concept of hooks for defining initialisation and access to application entry point which specific hosting mechanisms could interface with. Concepts from Paste deploy, buildout and bits of
Re: Pylons' redirect_to function does not work with HTTPS
On Aug 3, 12:13 pm, hekevintran hekevint...@gmail.com wrote: I have deployed a Pylons application on WebFaction and I am trying to use redirect_to in my controller. My page is using HTTPS. For some reason redirect_to is generating urls that are using HTTP for the protocol. I am currently getting around this problem by using the redirect function which allows you to supply a url as a string and hardcoding my urls. This works and is okay for now as my application is small, but it is very inelegant. Does anyone know why redirect_to is making urls that have HTTP and not HTTPS? Using WebFaction you would be sitting behind nginx and it would be nginx which is handling HTTPS. As a result your application is receiving HTTP only. Thus, wsgi.url_scheme wouldn't be set correctly for when connection to nginx was actually HTTPS. WebFaction do set a custom request header which is passed through to your application to indicate whether connection to nginx was HTTPS or not. You will need some sort of WSGI middleware which looks for that special request header and fixes up wsgi.url_scheme appropriately. As long as that is done, any conforming WSGI application should then do correct thing. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons' redirect_to function does not work with HTTPS
On Aug 3, 1:11 pm, hekevintran hekevint...@gmail.com wrote: Thanks Graham for the informative answer. What is the recommended solution to this situation? Effectively what I already said. I don't remember the name of the special header that WebFaction passes through and I don't know enough Pylons to say how you would integrate WSGI middleware wrapper to fix it up. Do a search on WebFaction's own forums as this issue has been discussed there before. Graham On Aug 2, 7:43 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Aug 3, 12:13 pm, hekevintran hekevint...@gmail.com wrote: I have deployed a Pylons application on WebFaction and I am trying to use redirect_to in my controller. My page is using HTTPS. For some reason redirect_to is generating urls that are using HTTP for the protocol. I am currently getting around this problem by using the redirect function which allows you to supply a url as a string and hardcoding my urls. This works and is okay for now as my application is small, but it is very inelegant. Does anyone know why redirect_to is making urls that have HTTP and not HTTPS? Using WebFaction you would be sitting behind nginx and it would be nginx which is handling HTTPS. As a result your application is receiving HTTP only. Thus, wsgi.url_scheme wouldn't be set correctly for when connection to nginx was actually HTTPS. WebFaction do set a custom request header which is passed through to your application to indicate whether connection to nginx was HTTPS or not. You will need some sort of WSGI middleware which looks for that special request header and fixes up wsgi.url_scheme appropriately. As long as that is done, any conforming WSGI application should then do correct thing. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons' redirect_to function does not work with HTTPS
On Aug 3, 3:28 pm, Mike Orr sluggos...@gmail.com wrote: On Sun, Aug 2, 2009 at 9:03 PM, hekevintranhekevint...@gmail.com wrote: I found a good solution. It will know which protocol to use if you specify it in the function call to redirect_to: return redirect_to(protocol='https', controller='myController', action='index') That's a workaround, yes. Is WebFaction doing proxying? Because my HTTPS application uses ProxyPass and the URLs are generated correctly even without the protocol option. Yes, WebFaction uses nginx in front. The nginx does: RequestHeader set Http-X-Forwarded-Proto https for HTTPS connection. There appears to be stuff in Paste to handle it. Just needs to be configured to use it I guess. http://trac.pythonpaste.org/pythonpaste/changeset/7458 Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Launching a background process
On Jul 27, 2:07 pm, Dave Forgac tylerd...@gmail.com wrote: I am trying to write an application that will allow a user to launch a fairly long-running process (5-30 seconds). It should then allow the user to check the output of the process as it is generated. The output will only be needed for the user's current session so nothing needs to be stored long-term. I have two questions regarding how to accomplish this: 1. What is the best way to launch a background process such as this with a Pylons controller? 2. What is the best way to get the output of the background process back to the user? Often the better way of doing this is to run a separate persistent long running process which has an XML-RPC interface and have the web application communicate with the back end process using XML-RPC. This avoids all the mess that can often occur with forking off a web application process. The back end might then perform the work by using a thread pool which consumes the queued up requests. The XML-RPC interface would still be active and allow for monitoring of state of a queued work item, or even stopping it if worker thread has a way to be flagged through the record for the work item. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Multiple applications with mod_wsgi
On Jul 21, 6:55 pm, Frank b...@metrico.lu wrote: Hello list, I am taking my first steps with pylons and really enjoy developing with it. Much better than my previous PHP experiences :-). But now on to my question: I plan to run several pylons applications on my server. One would be my CMS, another serves maps for internet and desktop gis mapping applications after the WMS standard, and the third planned would serve ajax requests for certain data. FWIW, you will find that Pylons folks would tend to recommend you run each with a separate Paste server instance behind mod_proxy of your preferred web server. Now I wonder if there are any problems concerning this setup. I would define several WSGIScriptAlias'es for different urls (/wms, or /ajax and /) No there isn't, however, if that is all you do then likely you will end up running it in embedded mode which would not be recommended, specially if you are still running mod_php and are therefore using prefork MPM with Apache. For why, see: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html You would be better off using mod_wsgi daemon mode and perhaps go as far as have a separate daemon process group for each application as well as force the application to run in the main interpreter of their respective processes to avoid issues with third party C extension modules for Python that don't work properly with sub interpreters. That said, even if run in same processes, mod_wsgi will ensure each is separated by running in separate sub interpreters of those processes. Do be aware that if they can run in the same interpreter, then you could always use Pylons to compose the applications together rather that using multiple WSGIScriptAlias directives. That is, use only one WSGIScriptAlias for '/' and let Pylons sort out mounting unique WSGI applications where required in one combine application. From how I understand the pylons book it is not possible to use virtualenv with mod_wsgi? I don't know what the Pylons book says, but one can use virtualenv with mod_wsgi. Read: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments it should be easy for me to avoid conflicting url name spaces, but is there more? As long as the WSGIScriptAlias directives are in correct order such that sub URL mounted applications come first, ie., before that for '/', no problem with mounting more than one application through mod_wsgi. If mounting under same site, only other thing I can think of off the top of my head that can cause issues is different applications using same cookie names and not restricting path for cookie to URL where application is mounted. Or should I setup a virtual host in apache for each application, maybe separated by a different port? There is no need for separate virtual hosts or ports. You would only need separate virtual hosts if you actually wanted them to be under different host names. If different sub URLs of same site is acceptable, then don't need to go to that extent. Any help setting up my server is greatly appreciated ... Ensure you read the actual mod_wsgi documentation and not rely on just what may be in Pylons documentation or anything you might find on some ones blog. Documentation is at: http://code.google.com/p/modwsgi/ Start with: http://code.google.com/p/modwsgi/wiki/InstallationInstructions http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: mod_wsgi and auth_kit: Login doesn't work
On Jul 21, 3:10 am, Damjan gdam...@gmail.com wrote: [Fri Jul 17 19:01:43 2009] [error] [client 192.168.1.100] TypeError: sequence of string values expected, value of type literal found, referer:http://192.168.1.100/ This seems like the common error in middleware to not return strings but probably a number in your case. You could try to wrap different middleware (AurhKit?) with wsgiref.validate to check it's conformance to the WSGI standard. http://docs.python.org/library/wsgiref.html#module-wsgiref.validate FWIW, this isn't a problem with response headers, where returning types other than strings is often a problem, but in the type of values yielded by the returned iterable, or as contained in the list returned. They should be strings and instead it is returning something else. I am not actually sure that wsgiref.validate properly checks that the iterable yields strings, so it may not pick it up correctly. At least my tests indicate that returning a non string from the iterable just gets passed straight through wsgiref.validate and still chokes on mod_wsgi. This could be viewed as a bug/deficiency in wsgiref.validate. Doesn't seem to be fixed in Python 3.1 either. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cannot import tmpl_context
On Jul 7, 12:43 pm, Mike Orr sluggos...@gmail.com wrote: On Sun, Jul 5, 2009 at 10:51 PM, apocalypznowapocalypz...@gmail.com wrote: I am running python 2.5.2 on a debian based box (mint 5) and I used the package manager to download pylons 0.9.6.1-1. In python shell, when I type: from pylons import tmpl_context I get: ImportError: cannot import name tmpl_context 'tmpl_context' is new in Pylons 0.9.7. It was called 'c' in earlier versions (and still is). Also, what is wrong with python 2.6 and pylons? Deprecation warnings and errors occur on the same import. I hesitate to show all the errors here as I read somewhere that 2.6 is not supported in linux. Is this true? The Pylons package in Ubuntu 9.04 (and I guess the Debian equivalent) is useless. The distros upgraded the default Python version but forgot to check Pylons' compatibility with it. Pylons 0.9.7 is compatible with Python 2.6, but it it was released too late to get into the distros. This will be rectified in the next distro releases. All virtualenvs have an 'activate_this.py' script, which I believe is for cases likemod_wsgithat have problems with regular virtualenvs. Actually, it is recommended that you don't use activate_this.py in mod_wsgi and not necessarily a good idea in mod_python either. This is documented in: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments Using virtual environments with Apache/mod_wsgi isn't that hard and is also explained in that document, so not sure what the issue was. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Set FormEncode translation while hosting as mod_wsgi
On May 28, 2:29 pm, Jan Koprowski jan.koprow...@gmail.com wrote: Hi ! When my app is run under Paster i18n works fine. After i switch to production environ (based on Apache with mod_wsgi) my Pylons messages translated inside my app works fine but for example (my lang directive in *.ini is set to pl) FormEncode messages is not translate. What I should to do ? 1) Copy all pl/FormEncode.po file to my application pl/myapp.po file ? 2) Add: lang = config['lang'] formencode.api.set_stdtranslation(domain=FormEncode, languages= [lang]) to: a) lib/base.py b) apache2/production.wsgi c) model/form.py Or anything else. Witch solutions is Pylons solution ? How are running application under mod_wsgi, using embedded mode or daemon mode? May relate to: http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Timezone_and_Locale_Settings Although that mentions timezone and locale settings, possible that language settings also affected. So, if running embedded mode and running other web applications, be they Python or PHP, which want a different language setting, you could get a conflict. This should be testable by ensuring you use daemon mode and have application run in its own process group. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: deploying to production?
On May 26, 1:57 am, Chris Withers ch...@simplistix.co.uk wrote: Chris Miles wrote: paster serve is a reasonable option. Like I said, mod_wsgi is preferred for me as it simplifies service control. Yes, there's a lot to be said for that... Most systems already know how to start and stop Apache... Is there a good how-to anywhere on serving with mod_wsgi? Did you try the web site? Start with: http://www.modwsgi.org/ http://code.google.com/p/modwsgi/wiki/InstallationInstructions http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines http://code.google.com/p/modwsgi/wiki/VirtualEnvironments Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: How setup (I guess) Pylons routes when app run under WSGIAlias /something
On May 19, 4:07 am, Marius Gedminas mar...@gedmin.as wrote:
On Mon, May 18, 2009 at 06:39:41AM -0700, Jan Koprowski wrote:
I use mod_wsgi 2.5 under Apache 2.
My WSGI applications is in /home/username/public_wsgi/wsgi/myapp.wsgi
where public_wsgi is directory where i have production.ini file.
My myapp.wsgi file looks like follows:
-- myapp.wsgi --
WORKING_ENV = /home/username/public_wsgi
APP_CONFIG = /home/username/production.ini
import sys
sys.path.append(WORKING_ENV)
from paste.deploy import loadapp
application = loadapp(config: + APP_CONFIG)
-- myapp.wsgi --
All looks working right when Pylons app runing under / address like
something.server.com/ but my app is hosted in server.com/something.
Apache configuration of WSGI:
-- WSGI apache config.py --
WSGIScriptAlias /panel /home/username/public_wsgi/wsgi/myapp.wsgi
WSGIDaemonProcess username user=username group=username processes=7
threads=17 display-name=wsgi:appname python-eggs=/username/public_wsgi/
data/eggs-cache
WSGIProcessGroup username
Directory /home/username/public_wsgi/wsgi
Order deny,allow
Allow from all
/Directory
-- WSGI apache config.py --
DocumentRoot for this serwer is set to /some/path/to/www and i don't
want change this. But after I host Pylons app under server.com/
something i get following errors in apache logs
File does not exist: /some/path/to/www/stylesheets, referer:
http://server.com/something/controllername/actionname
File does not exist: /some/path/to/www/images, referer:
http://server.com/something/controllername/actionname
What i should change to get working images/stylsheets links which
should bet getting from /home/username/public_wsgi/projectname/public
not DocumentRoot
There are two parts to the solution:
1. You have to generate correct URLs pointing to /panel/images/ and
/panel/stylesheets. This means using, e.g.
img src=${url('/images/foo.png')} /
instead of
img src=/images/foo.png /
It also means no static HTML files in your Pylons app public/
folder, unless those files use relative URLs
2. You have to tell your Pylons app that it lives at /panel and not at
the website root.
I don't know offhand how to do that with mod_wsgi. Maybe it already
does this automatically. AFAIU it's a matter of setting
SCRIPT_NAME and PATH_INFO correctly in the WSGI environment.
Apache/mod_wsgi sets SCRIPT_NAME appropriately based on mount point
derived from WSGIScriptAlias directive. Pylon's should honour it
automatically if Pylons is doing the correct thing.
Graham
I use Apache's mod_proxy + paster serve, and to get correct URLs from
the Pylons app I have
[filter:proxy-prefix]
use = egg:PasteDeploy#prefix
prefix = /control_panel
in my deployment.ini, and Apache has
ProxyPass /control_panelhttp://localhost:5000/control_panel
As an alternative, you could put Alias directives in your apache config
and point /images and /stylesheets to your WSGI app's public directory.
If you're fine with the URLs being /images and /stylesheets without the
/panel prefix, and if you're sure you won't encounter the same problem
with other static resources in your app's public/ subdir.
Marius Gedminas
--
Hacking graphics in X is like finding sqrt(pi) with roman numerals.
-- man xdaliclock
signature.asc
1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: AuthKit for Static Files
On Apr 7, 10:11 am, Jason Reid reid.ja...@gmail.com wrote: Nevermind; I should have just did a little more googling. If anyone is interested in this; it seems quite easy usingmod_wsgi for Apache. I dont care about the other ones really so no big deal.http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms Note that Apache is actually handling the HTTP Digest mechanism, the only thing that is being delegated to Python code is the generation of the hash for comparison of user details. Because that Python code runs embedded in Apache worker process, you should make it as absolutely minimal as possible if still running Pylons using Paste behind mod_proxy. In other words, don't just go importing all your Pylons/AuthKit infrastructure as it will only serve to bloat our the Apache worker process unnecessarily. Writing a custom bit of code which does only what you need would be the best approach. Graham They have a sample for django and I should be able to move that to Pylons quite easily. On Apr 6, 8:06 pm, Jason Reid reid.ja...@gmail.com wrote: I have not dived into Pylons yet; but the question I am curious about is how I would use AuthKit's authentication (digest specifically) too protect static content (I dont mean images; I am server rather large; over 4GB files) and I need them secured. I was using Django and it had a thing that let mod_python basically interface with its Authentication from apache. I dont know if AuthKit has that sort of feature; but how would I even configure that as Pylons is running through paste - however static content wouldn't be - or could it be efficiently? I am wondering if there is away to have AuthKit be my digest mechanism while using Apache2 or lighttpd or nginx (I would love a solution that encompasses all three :D) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Mar 30, 10:56 pm, Arun Tomar tomar.a...@gmail.com wrote: hi! well quite a discussion. just to add share my experience of developing on pylons deploying it. My requirement was to host multiple pylons application, on a single server. so running each app on paster daemon proxy to it via either apache or nginx was not a very optimal solution for me. So i tried using apache 2+ mod_wsgi, which is good works well, but it's a bit slow for now. i hope that in future it's performance will increase more. Apache/mod_wsgi performance with a typical Python web application should not be much different to other solutions. The mistake people often make in comparing it to others is that they don't take into consideration when benchmarking it that Apache/ mod_wsgi performs lazy loading where as others will often preload the application. Not realising this and factoring it into how you run your benchmarks, and/or not configuring Apache/mod_wsgi to preload the application can really screw up your results and give the impression that Apache/mod_wsgi performs poorly. If you have any remaining interest in Apache/mod_wsgi, you may perhaps want to go over to the mod_wsgi list and can review how you were actually setting up your system and performing the benchmarking and work out why you were seeing sub optimal performance. Even if there were an issue in Apache/mod_wsgi, things will never improve if you never feedback information about problems you may have encountered. Graham Then i tried nginx+mod_wsgi, which is great in terms of performance, speed scalability. You can just keep on adding different pylons webapps as virtual hosts to nginx everything works. so far it has been great. Our product is a website management system, ( you can say a CMS sort of app ). Ive deployed the nginx + mod_wsgi on our new VPS, and will be going live any day. -- Regards, Arun Tomar blog:http://linuxguy.in website:http://www.solutionenterprises.co.in --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Mar 29, 7:52 pm, Max Ischenko ische...@gmail.com wrote: Hi jj, On Sun, Mar 29, 2009 at 00:42, jose jj.gal...@gmail.com wrote: I can certainly sympathize here. ;) I have tried various deployment solutions as well for my work on developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki. It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different. Don't know if that was related to zombie issue you asked about on mod_wsgi list back in November or not. You were asked to supply some more specific information but you never responded. Bit hard to solve what ever problem it was when you don't followup about it. -( Anyway, all indications suggest it was something about your specific application, environment or configuration, as no general problem with mod_wsgi has come up which would explain such behaviour and no one else has reported anything like it. I do find though that a lot of problems people have are because they use embedded mode, especially with prefork, and do not bother to properly configure the Apache MPM settings to appropriate values for fat Python web applications. I have blogged about this previously in relation to mod_python, but also relevant to mod_wsgi embedded mode. http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html Graham Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy. And it all works amazingly good right now. I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. See alsohttp://unblog.developers.org.ua/2009/03/nginx.html If you are interested I guess I could post relevant configs here or to Pylons wiki -- Max.Ischenko // twitter.com/maxua --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Mar 30, 7:17 am, Jose Galvez jj.gal...@gmail.com wrote: Wow this discussion has been really great, I've learned quite a bit just following the different threads. Like I said I think there is room in the wiki for us to post better real world howto's with end to end config files. For example I could post my: 1) init script for supervisord (although I think the one Mike posted is better then mine so I'll most likely edit mine 2) the section in my supervisord.conf file 3) the sections in my apache conf files I would like to see the same thing from Max on how he did it with nginx and monit, and how Graham is serving his stuff with mod_wsgi. As mentioned in one of the posts mod_wsgi could use some better documentation and this might be a good way to do that. Do you mean better mod_wsgi documentation as part of the Pylons documentation, or that mod_wsgi itself needs better/more documentation? There is already quite a lot of documentation on mod_wsgi. It could be a bit better indexed but if one follows the main entry points from the mod_wsgi main page, it will get you to most stuff. http://code.google.com/p/modwsgi/wiki/InstallationInstructions http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines The index of everything is at: http://code.google.com/p/modwsgi/w/list The main ones pertinent to Pylons are: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/VirtualEnvironments There is also some information in the online Pylons book, although that does have at least one mistake in claiming that EvalException cannot be used with mod_wsgi. You just need to make sure you are running daemon mode with a single process. That is also mentioned in documentation: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Based_Debugger Graham Max also mentions upstartn, whats the advantage to that over using the system V script? Jose jose wrote: HI all, Just thought I would share what I've learned deploying pylons on both windows and linux loxes. First let me say right off the bat I absolutely love pylons I think hands down its the absolutely best web development environment out there. Having said that the biggest issue I see with pylons and wsgi apps in general, really has nothing to do with their ability to function as a framework, but its deployment. Now before anyone goes all read the wiki read the docs on me, I have so the rest of this is just my experience setting up pylons to run with Apache on both windows and linux (Ubuntu specifically). Now I love choices and if you want to connect your new pylons app to run under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python, and the ever present mod_proxy, and I've tried them all. For my money, both in terms of simplicity and in terms of development cycles mod_proxy is by far the easiest and I would venture to say the most stable. I did use mod_wsgi for a while, and will most likely use it on a limited project where running a pylons long running appp will be problematic, but mod_proxy just offers so much in the way of flexibility. Not to mention the fact that I just hate restarting apache just because I've made some minor change to one of my controllers. So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? On Windows the best solution I've come up with is my own Bourbon project, which I admit has all but died (I would love to give the code to someone to run with, I just really don't have the time to maintain it any longer). The reason I wrote it in the first place was allow give me a single windows service to manage all my running pylons apps without having to give each and every one its own windows service, which is a pain. Bourbon works pretty good, but at the moment you can't turn off or restart a single app, its all or nothing, which isn't very good. On Linux its a different story, there are a tun of ways to get a long running application up and running, and to some extent it depends on what distro you are using as to which is the best. On ubuntu I initially thought of writing rc init scripts for each app, but this quickly turned into a task that I didn't want to deal with, so I turned to mod_wsgi, which as I stated above for philosophical reasons I just didn't like. The I found, ok more likely stumbled upon after reading the wiki, supervisord. Finally something that makes sense (at least to me it really does). Now, after writing only a single rc init script to get supervisord running my pylons apps (and almost anything else I might have to start as a a daemon for that matter) is easily configured to run under the supervisord.conf file. I just love that thing. I know a best practices section goes against the grain for the pylons community because it is all about flexibility, but what
Re: What I've learned deploying pylons
On Mar 29, 11:05 am, Mike Orr sluggos...@gmail.com wrote: On Sat, Mar 28, 2009 at 4:42 PM, jose jj.gal...@gmail.com wrote: So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? I put all my Pylons and Quixote apps under Supervisord, with Apache mod_proxy. I want to try nginx when I have a chance. Some people prefermod_wsgibecause it runs everything under Apache processes, but I like being able to supervisor stop and supervisor start individual applications for maintenance and debugging, One can use signals to mod_wsgi daemon mode processes to restart them, as well as just touch the WSGI script file. It is only when you want to add or remove a completely new mod_wsgi daemon mode process that you need to 'restart' Apache after having done suitable configuration change. plus seeing them under their own names in the ps listing. The display-name option to WSGIDaemonProcess directive in mod_wsgi daemon mode allows you to assign it a name which shows in 'ps' output. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: modwsgi + Pylons gives segmentation fault
On Feb 24, 9:37 pm, cropr ruben.dec...@gmail.com wrote:
I am trying to setup mod_wsgi + Pylons on my deployment server (a
CentOS 5.2 machine), but I get this error message in the apache log
files
[Tue Feb 24 11:24:32 2009] [notice] child pid 12226 exit signal
Segmentation fault (11)
a standard wsgi test programs works fine.
The myapp.wsgi script is:
import os, sys
eggcache = '/var/www/vhosts/eggcache'
sys.path.append('/home/ruben/myapp')
os.environ['PYTHON_EGG_CACHE'] = eggcache
from paste.deploy import loadapp
application = loadapp('config:/home/ruben/myapp/development.ini')
The apache process has write access in the eggcache directory
If set debug = false in the development .ini
The setup works perfectly on my development machine
Any help how to debug
Have you read the documentation, in particular the sections which talk
about circumstances where crashes can occur.
http://code.google.com/p/modwsgi/wiki/InstallationIssues
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
Because you do not say which version of Python you are using, harder
to make a guess at what the issue may be.
Normally the problem is going to be a mismatch in shared library
versions used by Apache, PHP or some other Apache module and what a
Python module uses. In some cases the problem can be because of third
party Python modules not designed to run in sub interpreters. Not
knowing what your application does and what major Python modules/
packages it uses, again makes it harder to guess.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: clean up after session finished
On Feb 5, 1:40 pm, Mike Orr sluggos...@gmail.com wrote: On Wed, Feb 4, 2009 at 6:02 PM, Matt Feifarek matt.feifa...@gmail.com wrote: On Wed, Feb 4, 2009 at 3:10 PM, Mike Orr sluggos...@gmail.com wrote: You don't know when the user closes the browser. In fact, you don't know anything after the user's last request, whether you will hear from them again or not. Right, but I've always wanted this... although it is stateless, there is still an event we can use. The appserver knows when it cleans up or expires the session... couldn't we do an event hook there, something like on_expire()? That would be useful for the case of sessions that have external resources to clean up. I got a private question this week about having per-user SQLAlchemy engines. Those can't be pickled so they can't be stored in the session, so I suggested putting a dict on pylons.app_globals for them, but again you have the problem of expiring them. Pylons/Paste doesn't have a cron scheduler to sweep through and expire old sessions, but maybe it's time we added that. Or rather... it would only work with PasteHTTPServer. mod_wsgidoesn't have a Python server process to trigger the events or run them in. You could use WSGIDaemonProcess to create an additional daemon process and then use WSGIImportScript to preload script that triggers background thread to do any periodic processing. This daemon process wouldn't be used to handle requests, just to do background stuff. If only using a single process in daemon process group to handle requests, you could always just run the background thread in it. You only need a separate daemon process dedicated to it when using embedded mode or daemon mode with multiple processes in daemon process group. I had started on a wiki document about doing just this sort of thing, but only got it half way done. :-( Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Exploring ramework futures
On Jan 20, 10:31 am, Mike Orr sluggos...@gmail.com wrote: - it may be time to move to a post-WSGI standard a la the WSGI 2 proposals, since we'll have to change WSGI anyway. However, politically getting a WSGI update into the Python core is a long slow process, so maybe we should just do something under a new name. - Pylons 3 makes a good transition point, in that we can base the new tools on 2.6/3.0. I would agree that need to start looking towards WSGI 2.0 and Python 3.0 would be a good trigger for that. Not only would WSGI 2.0 be a good focus point for clarifying areas of current WSGI specification, would be a good point to look at more fundamental changes such as any required to support chunked request content and the concept of mutating input filters. It seems that chunked request content is becoming popular with mobile phone devices when posting data more than a certain size. At the moment WSGI cant handle chunked request content, so you can't use existing Python WSGI applications if you have a heavy focus on those sorts of clients. There are obviously various other things about current WSGI that people find annoying as well. Another area which needs to be fleshed out better is the initialisation of the environment that surrounds the application. In Paste server it does some initialisation of logging modules, mainly targeted at Pylons, which it can be argued it shouldn't. If hosting Pylons on another web hosting mechanism, you have to duplicate that internal initialisation that is being done by Paste server. So, some sort of abstraction for an application which ensures that such environment initialisation issues are also dealt with could be beneficial. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment
On Jan 14, 9:21 pm, Tycon adie...@gmail.com wrote: I installed modwsgi 2.3 and apache worker MPM and performance improved by 30% but CherryPy is still significantly faster. Which indicates that you definitely have something not right with your configuration or how you are running your tests. This is because the improvement in 2.X only applies to daemon mode. In embedded mode you should see about the same performance, irrespective of whether you switch form prefork to worker MPM. Even if you did switch to daemon mode, it can't be faster than embedded mode of 1.3. The only way that performance could improve is that the preloading issue I talked about was a factor, but if you haven't done anything about that, although worker may perform a bit better than prefork, your benchmarking would still appear to be out. Such variability simply calls into question your results and conclusions you are coming to. Graham On Jan 13, 10:58 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Jan 14, 2009 at 12:54 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Tue, Jan 13, 2009 at 11:51 PM, Tycon adie...@gmail.com wrote: Im using Ubunto 8.04 LTS and running the test using ab -n 1 -c 10 to localhost, in order to focus on the request handling code in the server stack and remove or reduce the weight of all other application logic such as db access and page rendering. This is not supposed to be a realistic timing of a real world request, but a highlight of the differences in efficiency of different request handling stacks including network layer, HTTP and routing code. All software package veriosns I'm using are the versions supplied in the OFFICIAL repositores for the distribution. Pylons and cherrypy were installed using (non)easy-install so their version is the latest rather than a version tied to any official repository. http://code.google.com/p/modwsgi/downloads/listdoesn'teven lists 1.x anymore as a note official debian package is 2.x http://packages.debian.org/changelogs/pool/main/m/mod-wsgi/mod-wsgi_2... now it seems ubuntu doesn't has a 2.0 package http://packages.ubuntu.com/hardy/libapache2-mod-wsgi sorry I was looking at the wrong ubuntu version it does have a 2.3 package as shown herehttp://packages.ubuntu.com/intrepid/libapache2-mod-wsgi but you are still running 1.3 as you posted above, so everything else still stands so your definitive results are totally coerced by the fact that your operating system is running outdated code for modwsgi, in other words you are running the very last version of a software with something that is almost 2 years old. And you expect us to believe it's not bias? lets run firefox 1.0 vs ie 7 today and see who is better, ummm wait bad example. But we are talking about competent projects here. I'm running in a full VM (single core) so I'm pretty sure my results are correct: CherryPy (started using paster serve prodduction.ini) is twice as fast (1300 req/sec for hello world) as Apache+modwsgi (650 req/sec). The only difference you may have is using worker MPM instead of pre-fork MPM, and newer versions of apche and modwsgi. In addition, apache is also logging the requests which is an additional overhead that pylons doesn't do in my configuration. But even so I doubt if Apache could match standalone pylons using CherryPy. On Jan 13, 8:36 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 3:10 pm, Tycon adie...@gmail.com wrote: Actually I have apache+modwsgi running flawlessly, and everything I said is based on meticulous performance benchmarking and theoretical profiling of deployment architectures. All benchmarks were performed on pylons full stack production mode, with debugging and logging turned off. The test was a simple hello world page with no template rendering, database access or other external links or references. Apache is prefork MPM v2.2.8 with modwsgi 1.3 using python 2.5.2. Old version of mod_wsgi. If using daemon mode of mod_wsgi then 2.X is somewhat faster. Using embedded mode, prefork especially can stuff up benchmarking because the burst in traffic will cause Apache to create lots of additional child worker processes to handle load. Every one of those then has to load application and that can kill machine performance while occurring, interfering with benchmark results. As such, for applications with high load cost, actually better to use daemon mode with fixed number of processes and with worker MPM for Apache. Stripping Apache of unused modules that take a lot of memory, especially PHP, is also advisable. The benchmarks CLEARLY show that using a stand-alone app server is MUCH faster then using apache+modwsgi to serve a page (returned from the aforementioned hello world controller action). When using CherryPy as the HTTP
Re: Recommended production deployment
On Jan 15, 12:36 am, Tycon adie...@gmail.com wrote: I specifically meant modwsgi's daemon mode is a hack, which is like I explained a proprietary The wire protocol used is actually only a slight variation on the wire protocol used by SCGI. The differences are that there is an initial handshaking to determine if daemon process feels it needs to restart before handling the request, and that header length information is as binary byte values rather than ascii, so that it can be decoded more efficiently. As mentioned by someone else the wire protocol is irrelevant as what is important is the WSGI API calling interface. As such daemon mode should be seen as a black box, the internals of which you shouldn't need to care about. unreliable I have not seen you report any bugs to the mod_wsgi list or issue tracker detailing how it is failing and neither has anyone else for that matter. The only known issue with the way daemon mode communication works is a blocking problem with large posts greater than system UNIX socket buffer size when content not consumed by application and it then in turn sends a response greater than UNIX socket buffer size. This problem also affects mod_scgi, mod_cgi, mod_cgid and theoretically in some configurations mod_proxy (from reading source code). In case of mod_proxy it probably is hard to trigger as it is using INET sockets and not UNIX sockets. Only platform this issue really affects is those with very small default UNIX socket buffer size like MacOSX. To cope with this there are configuration options in mod_wsgi to increase the buffer sizes. There are also socket timeouts to detect the situation and recover from it automatically. In practice, no one has been reporting the problem in real installations. and non scalable communication protocol. As I explained previously and which you are ignoring, horizontal scaling is performed exactly like you would with any web server. You stick a proxy/load balancer in front and spread everything across multiple machines in a cluster. There is actually specific code in mod_wsgi to deal with this situation for case where each machine only has a single daemon process, but many processes across a cluster. The feature is a way of ensuring that wsgi.multiprocess flag is set correctly to True rather than False as would be case when only one machine on a process. For other WSGI hosting mechanisms have seen, not sure they have a way of overriding this and so each machine thinks it has the only process, which is wrong. If applications rely on wsgi.multiprocess they could then behave incorrectly. Only answer in that case is to hack a WGSI middleware into stack that overrides it. BTW, technically FASTCGI is not faster. This is because with FASTCGI you have to use flup code. Being Python code that slows things down much more than the pure C code in the mod_wsgi daemon process doing the same thing. As for embedded mode, it's not a hack but as it turns out its performance isn't all that great given that it under-performs a pure python HTTP server like the one in CherryPy. Which is still debatable, plus have already pointed out, the differences get swallowed up as noise in overall request time as this isn't where your bottleneck is going to be. As I pointed out right at the beginning. Even when you try and correct the misinformation that people put out, they still don't change their tune. As such, this is all the time I am going to waste on this. I will though do again my own benchmarking. Maybe CherryPy WSGI server has improved since last time I looked. Either way I am not going to be too concerned as I am not out to make Apache/mod_wsgi the fastest thing in the world, nor am I expecting everyone to use it. I work on it purely because I find it an interesting thing to work on. So, as I always say, use whatever you feel like using, but if you are going to try and discredit other options, please back it up with real evidence in the way of actual benchmark data and configuration information, which you still haven't done so. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment
On Jan 14, 10:42 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Jan 13, 2009 at 6:52 AM, Tycon adie...@gmail.com wrote: Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app server. As such, it has the same theoretical performance as reverse proxy and fcgi (which in fact provide the same performance), but it uses a proprietary communication protocol, and inlike proxy or fcgi, it requires the app and web server processes to be on the same machine Is *that* what you're talking about when you say daemon mode and proprietary protocol. I thought you meant daemon mode as in running PasteHTTPServer or CherryPy as a daemon, and proprietary protocol as in WSGI or SCGI. The main point of mod_wsgi's daemon mode is to isolate bugs/memory leaks between the web application and the server, and to track the application's individual resource usage in the 'ps' listing. It's not designed for multi-machine scalability. As for its proprietary protocol, I consider that an internal matter of mod_wsgi. What matters is whether it works, and I haven't heard any complaints in that regard. Ultimately it comes down to the sysadmin's time of setting up mod_wsgi now and possibly switching to something else later, vs setting up something multi-machine scalable now (which is more work up front). And that depends on how likely a traffic onslaught is, how quickly the load will accelerate, and the sysadmin's future availability. You don't need to switch to something else when you want to go to a multi machine configuration. This is just part of the FUD that they were pushing on the irc channels in the past to try and discredit Apache/mod_wsgi. It just seems that Tycon is parroting this same message. I wouldn't be surprised if he has never even used Apache/ mod_wsgi. Certainly the originator of a lot of this FUD on the irc channels in the past freely admitted he had installed neither mod_python or mod_wsgi with Apache. When you want to start looking at horizontal scaling you do exactly what you would do were you scaling up Apache for any other scenario. That is, you stick perbal, pound, nginx or some other proxying/load balancing solution in front and run an Apache instance of each of the machines in your cluster. Since running nginx in front of Apache/mod_wsgi to handle static files is a common scenario, that same nginx instance could be used for the job, given that it still likely going to handle the load of both static files and proxying fine because of being event driven rather than threaded. Hmmm, this sounds exactly like what is because suggested if using paste server or cherrypy wsgi server. Strange that. When you read this persons other posts I think it is quite clear that he doesn't really understand the difference between the WSGI specification and mod_wsgi as an implementation of it. Specifically that WSGI is a programmatic API and not a wire protocol. It is also questionable how much he knows how to setup Apache and mod_wsgi. Probably will never see anything about how they actually configured Apache and mod_wsgi for these benchmarks that he surely must have run to come to these conclusions. Like most benchmarks they are probably flawed due to not setting up his tests properly so equal comparison was being performed, or not even benchmarking something realistic. What I find particularly clueless about comparisons between different hosting mechanisms for dynamic web applications is that they quite often test a hello world application and not a real application. As such any figures are pretty meaningless given that any difference between different hosting mechanism is likely in milliseconds. When for a large application the overall request time is in the 10-100 milliseconds, the difference just disappears as noise within the real bottleneck which is the application and or database access. Add on top of that that you would never want to run your web server at maximum capacity on an ongoing basis, you would generally have more than enough headroom even if different hosting solutions perform a bit different, thus differences don't matter anyway. Overall one would be much better off focusing your time on improving the performance of your application and database access than having a pissing contest about raw request throughput for some unrealistic pattern of traffic that your site will never experience. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment
On Jan 14, 3:10 pm, Tycon adie...@gmail.com wrote: Actually I have apache+modwsgi running flawlessly, and everything I said is based on meticulous performance benchmarking and theoretical profiling of deployment architectures. All benchmarks were performed on pylons full stack production mode, with debugging and logging turned off. The test was a simple hello world page with no template rendering, database access or other external links or references. Apache is prefork MPM v2.2.8 with modwsgi 1.3 using python 2.5.2. Old version of mod_wsgi. If using daemon mode of mod_wsgi then 2.X is somewhat faster. Using embedded mode, prefork especially can stuff up benchmarking because the burst in traffic will cause Apache to create lots of additional child worker processes to handle load. Every one of those then has to load application and that can kill machine performance while occurring, interfering with benchmark results. As such, for applications with high load cost, actually better to use daemon mode with fixed number of processes and with worker MPM for Apache. Stripping Apache of unused modules that take a lot of memory, especially PHP, is also advisable. The benchmarks CLEARLY show that using a stand-alone app server is MUCH faster then using apache+modwsgi to serve a page (returned from the aforementioned hello world controller action). When using CherryPy as the HTTP server for pylons, the req/sec is almost twice as fast as apache+modwsgi. PasteHTTP is 15% slower than CherryPy but still much faster then Apache+modwsgi. Generally contrary results on MacOSX, with both CherryPy and Paste server running quite badly in comparison. On Ubuntu CherryPy runs about the same and Paste server slower. What operating system are you using? Did your tests take into consideration that Apache/mod_wsgi lazy loads application object on first request where as the others preload. This in part plays into why benchmarking results can look bad with Apache/ mod_wsgi, people are actually counting startup costs when they shouldn't. Graham But of course using a stand-alone app-server as the web-server has a few drawbacks: 1. Static files are also served by pylons, which is slow. 2. Cannot use multiple processes, which is required to make optimal use of system resources and allow for scalability across multiple CPUs and multiple machines. So in most cases you will want to have a reverse proxy front-end that acts as a load balancer as well as serve the static files. As you mention, nginx is a good choice. In this configuration, I would assume it would be better to have nginx forward the requests directly to a pool of standalone pylons app-servers, rather than to a pool of apache +modwsgi processes. So, while using only standalone CherryPy to serve a pylons app has some drawbacks, those drawbacks are avoided if using reverse proxy that serves as a load balancer and to serve static files. So when is it best to use apache+modwsgi ? If we have a single node with mutiple cores and a lot of RAM, and we need to serve a lot of static files, then apache+modwsgi would be better than using a standalone app server. But even for this scenario, nginx as a reverse proxy gives about the same performance. On Jan 13, 5:53 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 10:42 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Jan 13, 2009 at 6:52 AM, Tycon adie...@gmail.com wrote: Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app server. As such, it has the same theoretical performance as reverse proxy and fcgi (which in fact provide the same performance), but it uses a proprietary communication protocol, and inlike proxy or fcgi, it requires the app and web server processes to be on the same machine Is *that* what you're talking about when you say daemon mode and proprietary protocol. I thought you meant daemon mode as in running PasteHTTPServer or CherryPy as a daemon, and proprietary protocol as in WSGI or SCGI. The main point of mod_wsgi's daemon mode is to isolate bugs/memory leaks between the web application and the server, and to track the application's individual resource usage in the 'ps' listing. It's not designed for multi-machine scalability. As for its proprietary protocol, I consider that an internal matter of mod_wsgi. What matters is whether it works, and I haven't heard any complaints in that regard. Ultimately it comes down to the sysadmin's time of setting up mod_wsgi now and possibly switching to something else later, vs setting up something multi-machine scalable now (which is more work up front). And that depends on how likely a traffic onslaught is, how quickly the load will accelerate, and the sysadmin's future availability. You don't need to switch to something else when you want to go
Re: Recommended production deployment (was: Re: Is Pylons a meta-package ?)
On Jan 14, 2:32 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Mon, Jan 12, 2009 at 2:22 PM, Tycon adie...@gmail.com wrote: No, mod_wsgi is a hack. Embedded mode is bad, no serious website is running app server embedded in web server. Daemon mode is even more stupid, an unstable (and non scalable) way of using web server to manage the app server, and invent a new communication protocol between them, when standard ones that support distributed architecture already exist. you are right no self respecting site will use that piece of junk! although I saw this email some time agohttp://groups.google.com/group/modwsgi/browse_thread/thread/88de3e07e... so you may reconsider that statement given this line. Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2 mod_wsgi/2.3 Server at pypi.python.org Port 80 The pycon site mustn't know what they are doing either. ;-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment (was: Re: Is Pylons a meta-package ?)
On Jan 13, 7:44 am, Dalius Dobravolskas dalius.dobravols...@gmail.com wrote: On Mon, Jan 12, 2009 at 10:22 PM, Tycon adie...@gmail.com wrote: No, mod_wsgi is a hack. Embedded mode is bad, no serious website is running app server embedded in web server. Daemon mode is even more stupid, an unstable (and non scalable) way of using web server to manage the app server, and invent a new communication protocol between them, when standard ones that support distributed architecture already exist. Tycon, are you talking about nginx's mod_wsgi or apache's mod_wsgi. That's two completely different projects IMHO. As for mod_wsgi on Apache I doubt that it is not scalable. At least it should be as much scalable as Apache. And it is not hack it is WSGI implementation for Apache. Graham could answer better here. I have learned that there is no point trying to counter these sorts of accusations. They never want to provide proof of why what they claim is true and even when you point out where their arguments are wrong, make no sense, or have been proven otherwise through actual use, they don't listen and just keep repeating the same FUD. They also never want to accept the basic concept of choice and that different systems are going to suit different peoples requirements or mindsets. The #pylons, #wsgi and #python.web irc channels seem to be a breeding ground for this sort of stuff. If I didn't know any better I would think this Tycon is the twin brother of one particular person on those irc channels. Although, that other person may have toned down their rhetoric by now, I haven't bothered to check lately what they are saying. It is pretty sad really, I would be quite happy adding those irc channels to my watch list and helping out people with WSGI, mod_wsgi, mod_python and Apache questions, but I don't because I would have to spend most of my time just countering the FUD that was being put around about both mod_python, mod_wsgi and use of Apache. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: passing on 404 errors?
On Jan 4, 9:06 pm, Max Ischenko ische...@gmail.com wrote: Hello, Merry holidays everyone! I want to disable 404 error handling by wsgi/pylons so that apache handler would run. I'm using mod_wsgi behind apache and now I get Not Found page with hr noshade div align=rightWSGI Server/div in the footer. I guess that's what mod_wsgi do. How can I tell it to leave the 404 error alone? You can't do it with Apache/mod_wsgi, at least not right now. What is required is an equivalent to ProxyErrorOverride as would be used if using mod_proxy and Paste HTTP server behind Apache. In other words, you would use optional configuration to say that an error response from the WSGI application should effectively be ignored, except for the status code, and that instead Apache should yield the response content for that error status. Implementing this for mod_wsgi daemon mode wouldn't be that hard as you can just read and discard the data read from daemon process and not pass it back. Implementing it for embedded mode is much harder though as there is direct writes to the Apache filter chain and various other issues. Anyway, the specific mod_wsgi issue for this feature is: http://code.google.com/p/modwsgi/issues/detail?id=57 Although I created an issue for it, no one has actually ever asked for this feature so it has been given quite low priority. So, if you really need this ability in a hurry, run Paste server behind Apache with mod_proxy and use ProxyErrorOverride directive. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: passing on 404 errors?
On Jan 4, 9:27 pm, Max Ischenko ische...@gmail.com wrote: Anyway, the specific mod_wsgi issue for this feature is: http://code.google.com/p/modwsgi/issues/detail?id=57 Although I created an issue for it, no one has actually ever asked for this feature so it has been given quite low priority. So, if you really need this ability in a hurry, run Paste server behind Apache with mod_proxy and use ProxyErrorOverride directive. Thanks for the explanation! I guess I could live with two 404 pages then, not that a big deal. Except I perhaps part misread part of your problem. Whatever is setting: hr noshade div align=rightWSGI Server/div it isn't mod_wsgi as it will just pass on whatever responses are supplied by the WSGI application. Thus, if you want to get rid of that, search out where in Pylons or your application it is being generated and override error response page generated by Pylons through whatever mechanism Pylons has for that. BTW, if you want one consistent 404 page used by both Apache and the WSGI application, then set Apache directive: ErrorDocument 404 /some/url/for/404/page Where that URL references the URL within Pylons application for the 404 page. In other words, have WSGI application generate the 404 for the rest of Apache. Graham -- Max.Ischenko http://www.developers.org.ua The #1 Ukrainian Software Developers' community News, Companies, Jobs, Events, Talks and more --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Problem with redirect_to and SSL
The real problem here is probably because Pylons server is only
accepting HTTP connections and so wsgi.url_scheme in WSGi environment
is always 'http' and doesn't reflect that a connection is originally
being accepted by Apache as HTTPS.
For discussion of similar issue when nginx is used as proxy, accepting
both HTTP and HTTPS, and with Apache/mod_wsgi behind but only
accepting HTTP, see:
http://groups.google.com/group/modwsgi/browse_frm/thread/94f952720c878506
In short, you need to have proxy front end pass some indication that
HTTPS was used for original requests and use a WSGI middleware/
application wrapper check for that flag and reset wsgi.url_scheme to
correct value based on how request was accepted by the proxy.
Sure someone here can indicate best way of achieving this with Pylons.
Graham
On Dec 22, 9:36 pm, Andre Kolell andre.kol...@bluesummit.de wrote:
I solved the problem regarding redirect_to and SSL by using mod_rewrite to
redirect each http-request to https:
NameVirtualHost *:80
virtualhost *:80
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
/virtualhost
I'm not sure if this is an adequate solution.
- Ursprüngliche Mail -
Von: Andre Kolell andre.kol...@bluesummit.de
An: pylons-discuss@googlegroups.com
Gesendet: Freitag, 19. Dezember 2008 16:51:57 GMT +01:00
Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Problem with redirect_to and SSL
Hello,
I'm using Apache with SSL and use it's Proxy functionality to forward
requests to the local running Paster (with Pylons 0.9.7rc2). SSL and Links
work fine (with Mako). Only when Pylons comes to use the redirect_to-function
it always ends up in http- instead of https-Connections. Using
protocol='https' as a redirect_to-Parameter only solves my problem at first
view, but as I'm developing local without SSL, it's not really a solution.
I also seems as if request.environ['wsgi.url_scheme'] gives me http instead
of https. May be redirect_to uses request.environ['wsgi.url_scheme']?
Does anyone know why redirect_to doesn't use SSL-Connections and how I can
make redirect_to using them?
Best regards,
Andre
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Nov 27, 6:03 am, Gustavo Narea [EMAIL PROTECTED] wrote: Hello, everybody. I'm writing to let you know about the authorization framework I have been working on, repoze.what:http://static.repoze.org/whatdocs/ Some of its features are: * Web framework independent. * Authorization only. It will only do authorization and nothing else. * _Highly_ extensible. * _Fully_ documented. * Your application's `groups` and `permissions` may be stored in an SQLAlchemy managed database, thanks to the SQL plugin (repoze.what.plugins.sql). * The only requirement is that you use the repoze.who authentication framework (which is configured for you by repoze.what). Why is it dependent on repoze.who? A nicely decoupled system would only need to know that authentication had succeeded which generally is identifiable by REMOTE_USER being set in the WSGI environment dictionary passed from outer middleware, where outer middleware has performed authentication, or even where it didn't and REMOTE_USER was set by a web server capable of doing authentication itself such as Apache. Graham * It's not hard to get started! It's not a stable software yet, but it's just reached its first beta. Cheers! -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware:http://www.getgnulinux.org/ signature.asc 1KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Nov 28, 12:13 am, Dalius Dobravolskas [EMAIL PROTECTED] wrote: Hello, Gustavo, On the other hand, because REMOTE_USER (which isn't set by r.who) is not always enough and also some of the future features will rely on future/existing repoze.who plugins, for example: I agree with that. Even more REMOTE_USER is not enough to distinguish between different authentication methods when multiple methods are used. Does that mean you ignore AUTH_TYPE variable passed in from Apache where Apache module performs the authentication? Graham Because of that I offer to do following in r.who: Set REMOTE_USER as username. Usually all authentication systems provides one or another form of username. Set x-wsgiorg.user_data with data dict (e.g. certificate details, OpenID SREG data and etc.). Name was proposed by Ian Bicking. This way r.who and r.what will be compatible with other authentication and authorization solutions. -- Daliushttp://blog.sandbox.lt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: mod_wsgi and virtualenv
On Nov 10, 11:15 pm, Christoph Haas [EMAIL PROTECTED] wrote:
Hi,
I'm trying to deploy a Pylons app via mod_wsgi (Apache). That works so far.
But I want to use a virtualenv directory and can't find any documentation
on it. I found something for workingenv but don't know how to translate
that to virtualenv.
http://code.google.com/p/modwsgi/wiki/VirtualEnvironmentssaid something
about WSGIPythonHome but that can't be defined per virtual host. So I
would have to use the very same virtualenv directory for all deployed
applications (which is pretty absurd).
Did you read that document completely or did you just scan it and try
and cherry pick out of it what you thought may work?
The mod_wsgi document explains that WSGIPythonHome is for linking
mod_wsgi against virgin Python virtual environment so that site-
packages in system wide Python is ignored. As also described,
additional virtual environment directories are then applied to
embedded mode or daemon mode processes using WSGIPythonPath or python-
path option to WSGIDaemonProcess directive as appropriate. If running
multiple VirtualHosts in embedded mode, then use site.addsitedir()
instead as described. Otherwise, delegate each VirtualHost to its own
daemon process and use python-path option for that daemon process
group instead.
I also
foundhttp://pypi.python.org/pypi/virtualenv#using-virtualenv-without-bin-p...
but that just prints these lines into Apache's error.log:
The virtualenv document talks about 'activate_this.py' not 'activate'
in that section.
The mod_wsgi document also says not to use the activate_this.py script
included in virtualenv 1.3 anyway.
You might want to read both the mod_wsgi and virtualenv document
again, as well as reading other documentation on the mod_wsgi site if
you don't understand the difference between embedded mode and daemon
mode.
Graham
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21] mod_wsgi
(pid=26216): Target WSGI script '/etc/apache2/screenshots.debian.net.wsgi'
cannot be loaded as Python module.
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21] mod_wsgi
(pid=26216): Exception occurred processing WSGI
script '/etc/apache2/screenshots.debian.net.wsgi'.
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21] Traceback (most
recent call last):
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21]
File /etc/apache2/screenshots.debian.net.wsgi, line 8, in module
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21]
execfile(activate_this, dict(__file__=activate_this))
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21]
File /home/debshots/bin/activate, line 4
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21] deactivate ()
{
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21]
^
[Mon Nov 10 13:12:23 2008] [error] [client 80.85.196.21] SyntaxError:
invalid syntax
Seems like it can't run virtualenv's 'activate' script like that. :(
Any ideas?
Kindly
Christoph
signature.asc
1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Fwd: composite Django/Pylons app gives strange error under mod_wsgi
Parallel discussion in mod_wsgi group at:
http://groups.google.com/group/modwsgi/browse_frm/thread/4db401c9d5d308a6
Graham
Max Ischenko wrote:
May be you guys know how Pylons WSGI app can conflict with Django. There is
a conflict, since if I comment out call to loadapp() the django app starts
working.
-- Forwarded message --
From: Max Ischenko [EMAIL PROTECTED]
Date: Tue, Nov 4, 2008 at 13:01
Subject: composite Django/Pylons app give strange error
To: modwsgi [EMAIL PROTECTED]
Hello,
I'm trying to run Django/Pylons app under mod_wsgi and get this error:
mod_wsgi (pid=9231): Exception occurred processing WSGI script '/var/
www/site-djangoapp/django.wsgi'.
Traceback (most recent call last):
File /var/www/site-djangoapp/py/lib/python2.5/site-packages/django/
core/handlers/wsgi.py, line 239, in __call__
response = self.get_response(request)
File /var/www/site-djangoapp/py/lib/python2.5/site-packages/django/
core/handlers/base.py, line 72, in get_response
urlconf = getattr(request, urlconf, settings.ROOT_URLCONF)
File /var/www/site-djangoapp/py/lib/python2.5/site-packages/django/
conf/__init__.py, line 32, in __getattr__
return getattr(self._target, name)
File /var/www/site-djangoapp/py/lib/python2.5/site-packages/django/
conf/__init__.py, line 147, in __getattr__
return getattr(self.default_settings, name)
AttributeError: 'module' object has no attribute 'ROOT_URLCONF'
I'm using virtualenv python. Here is relevant Apache config lines;
WSGIPythonHome /var/www/site-djangoapp/py
VirtualHost *
WSGIProcessGroup max
WSGIDaemonProcess max user=max group=www-data threads=2 maximum-
requests=1000
WSGIScriptAlias / /var/www/site-djangoapp/django.wsgi
/VirtualHost
My django app is at doudj package and my pylons app is at doupy
package.
Executing module content from the command line works:
$ python django.wsgi
$ type python
python is hashed (/var/www/site-djangoapp/py/bin/python)
$ cat django.wsgi
import sys
import os
import os.path
heredir = os.path.dirname(__file__)
sys.path.insert(0, heredir)
os.environ['DJANGO_SETTINGS_MODULE'] = 'doudj.settings'
import doudj.settings
assert doudj.settings.ROOT_URLCONF, doudj.settings
from django.core.handlers.wsgi import WSGIHandler
django_app = WSGIHandler()
from paste.deploy import loadapp
doupy_app = loadapp('config:config.ini',
relative_to=os.path.join(heredir, 'doupy'))
application = django_app
And here is where the mystery starts.
If I comment out loadapp() call to init my Pylons app it magically
starts working. If I re-enable it I get that AttributeError in
_django_ code. And I have no idea why I don't observe the error from
the command line.
I need your help guys.
Max.
--
Max // http://maxischenko.in.ua
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: IOError: request data read error
On Oct 16, 1:24 am, Wayne Witzel [EMAIL PROTECTED] wrote: Anyone else experiencing this error? I am getting WebApp Error mails, the error occurs 5-10 times a day on my production site. Unable to find a pattern or reproduce it. Currently running under Apache 2.2 andmod_wsgiwith the 0.9.6 version of Pylons. From looking at the error, it seems as if the request is made by the client and in the process or doing so the connection is aborted before it can complete? Yep. Can happen if user aborts request, presses reload etc, while upload still occurring. Its one of those things that can happen and depending on what the request handler is doing, it would need to be tolerant to it. For example, if handler has acquired resources it would need to release them when exception propagated back. Or, if it was saving data into temporary file for later processing, it should perhaps then remove the temporary file. In other words, you can't assume that reading request content from a client is always going to succeed. Actions by the client, or any range of network issues could cause a failure to read input. Unfortunately in WSGI specification there is no standardised exception which should be raised when there is a problem reading data from wsgi.input. Most WSGI hosting mechanisms would raise an IOError, but that is necessarily guaranteed. Graham Search around, best I found I was an open ticket that might be related:http://trac.pythonpaste.org/pythonpaste/ticket/221 Module paste.exceptions.errormiddleware:137 in __call__ try: __traceback_supplement__ = Supplement, self, environ app_iter = self.application(environ, start_response) return self.make_catching_iter(app_iter, environ) except: app_iter = self.application(environ, start_response) Module pylons.wsgiapp:315 in __call__ def __call__(self, environ, start_response): environ['pylons.environ_config'] = self.econf return self.app(environ, start_response) return self.app(environ, start_response) Module beaker.cache:180 in __call__ environ['paste.registry'].register(self.cache, self.cache_manager) environ[self.environ_key] = self.cache_manager return self.app(environ, start_response) return self.app(environ, start_response) Module beaker.session:405 in __call__ return start_response(status, headers, exc_info) try: response = self.wrap_app(environ, session_start_response) except: ty, val = sys.exc_info()[:2] response = self.wrap_app(environ, session_start_response) Module routes.middleware:58 in __call__ log.debug(_method found in QUERY_STRING, altering request method to %s, environ['REQUEST_METHOD']) elif is_form_post(environ) and '_method' in req.POST: old_method = environ['REQUEST_METHOD'] environ['REQUEST_METHOD'] = req.POST['_method'].upper() elif is_form_post(environ) and '_method' in req.POST: Module paste.wsgiwrappers:213 in POST ``charset`` is set. params = self._POST() if self.charset: params = UnicodeMultiDict(params, encoding=self.charset, params = self._POST() Module paste.wsgiwrappers:195 in _POST def _POST(self): return parse_formvars(self.environ, include_get_vars=False) def POST(self): return parse_formvars(self.environ, include_get_vars=False) Module paste.request:174 in parse_formvars fs = cgi.FieldStorage(fp=input, environ=environ, keep_blank_values=1) environ['QUERY_STRING'] = old_query_string if fake_out_cgi: keep_blank_values=1) Module cgi:532 in __init__ self.done = 0 if ctype == 'application/x-www-form-urlencoded': self.read_urlencoded() elif ctype[:10] == 'multipart/': self.read_multi(environ, keep_blank_values, strict_parsing) self.read_urlencoded() Module cgi:637 in read_urlencoded def read_urlencoded(self): Internal: read data in query string format. qs = self.fp.read(self.length) self.list = list = [] for key, value in parse_qsl(qs, self.keep_blank_values, qs = self.fp.read(self.length) IOError: request data read error --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: error running same pylons app with two different databases under mod_wsgi
On Oct 8, 9:07 pm, Dunk Fordyce [EMAIL PROTECTED] wrote: Hello, We've got a bit of an odd error with sqlalchemy. The situation is we're running the same pylons app under two subdomains each connected to a different database. Each app sits in its own virtualenv but is the same code. Each connects to a different mysql database. The first app runs fine and has done for some time, when we try and use the second however we're seeing: InvalidRequestError: Table 'accounts' is already defined for this MetaData instance. Specify 'useexisting=True' to redefine options and columns on an existing Table object. Im 90% sure this is an issue with mod_wsgi ( or how we have set it up) as I can run the second instance with paster serve without this error. Can anyone give any hints as to how to fix this or to further debug the problem? We are running mod_wsgi 2.0 in daemon mode and sqla 0.4.5. In mod_wsgi, separate sub interpreters are used to separate WSGI applications. Because of how Python works/is implemented, the isolation between them isn't perfect. Two areas where there can be problems are leakage of os.environ variables between sub interpreters and third party C extension modules which aren't implemented to properly work in multiple sub interpreters at the same time. Thus, depending on how MySQL module is implemented, it could be misbehaving in such a situation. What you would be best off doing is use mod_wsgi daemon mode to create separate daemon process groups to run each WSGI application (virtual host) within. That way they run in separate processes and can't interfere with each other. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: error running same pylons app with two different databases under mod_wsgi
I have seen a number of times where people have setup WSGIDaemonProcess directive to create daemon process groups, but then forget to also setup WSGIProcessGroup directive in appropriate context to delegate application to daemon process. That or if they do add WSGIProcessGroup directive, they don't place it in correct context. To verify, print out from WSGI environ dictionary the value of 'mod_wsgi.process_group' attribute. Graham On Oct 9, 12:27 am, Dunk Fordyce [EMAIL PROTECTED] wrote: hrmmm i think there might of been some developer error or something because after changing the display-names everything seems to be working ok... perhaps something got confused. On Wed, Oct 8, 2008 at 1:48 PM, Dunk Fordyce [EMAIL PROTECTED]wrote: Hi thanks for the quick response, What you would be best off doing is use mod_wsgi daemon mode to create separate daemon process groups to run each WSGI application (virtual host) within. That way they run in separate processes and can't interfere with each other. We are actually running in daemon mode so I'm very confused! To make absolutely sure about deamon mode I just changed the display-name of each process and i can indeed see two different processes running. Perhaps that signifies the problem lies elsewhere... altho as it runs with paster serve so Im still without a clue --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: HEAD request and internal server error
On Sep 17, 10:59 am, Petr Kobalíček [EMAIL PROTECTED]
wrote:
Hi Wyatt,
my biggest problem with this is that HEAD requests are used by bots,
so the pylons pages are not indexable at all. This is big problem for
me and I don't know how to solve this, because we are creating
ecommerce software using pylons, sqlalchemy and qooxdoo for
administration. I'm using pylons also for my web and here I found the
problem:-(
So, any ideas ;-) ?
A workaround is to wrap your WSGI application in a middleware which
changes REQUEST_METHOD from HEAD to GET and which discards the
iterable returned from the application. The middleware should ensure
it still calls close() on the iterable properly though as per WSGI
specification requirements.
Alternatively, you could make it work by hosting with Apache/mod_wsgi
and configuring Apache to enable Apache CONTENT_LENGTH output filter
for the application. This will work as when an Apache output filter is
configured, mod_wsgi will convert a HEAD request to a GET request
before passing it to the WSGI application. This is done so that actual
response content can be passed back to the Apache output filter, which
may want to adjust response headers based on the content. Apache will
discard any response content after any output filters are done with it
and will not send it back to the client.
If this isn't done with Apache/mod_wsgi, the HEAD and GET requests may
not yield the same response headers. The CONTENT_LENGTH output filter
is chosen here purely because it is pretty benign, any Apache output
filter would have been enough to trigger this behaviour.
Graham
Cheers
- Petr
2008/9/17 Wyatt Baldwin [EMAIL PROTECTED]:
On Sep 16, 3:18 pm, Petr Kobalíček [EMAIL PROTECTED] wrote:
So it's related to this
ticked:http://pylonshq.com/project/pylonshq/ticket/507
I can't solve this bug myself, can anybody help me ? (I'm now using
pylons from mercurial, but without success)
Cheers
- Petr
2008/9/16 Petr Kobalíček [EMAIL PROTECTED]:
So,
this is pylons bug !
I tried to create plain application and to add hello controller
(that's in documentation).
The i tried this script:
import httplib
req = httplib.HTTPConnection(localhost:5000)
req.request(HEAD, /hello/index)
res = req.getresponse()
print res.status, res.reason
Ad I got internal server error
Exception: No content returned by controller (Did you remember to
'return' it?) in: 'HelloController'
So, what to do, is there any solution ?
Cheers
- Petr
2008/9/16 Petr Kobalíček [EMAIL PROTECTED]:
Hi devs,
I have problem with HEAD requests that causes me Internal server error.
The error exception:
Exception happened during processing of request from ('127.0.0.1', 4948)
Traceback (most recent call last):
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
httpserver.py, line 1056, in process_request_in_thread
self.finish_request(request, client_address)
File C:\PROGRA~1\Python25\lib\SocketServer.py, line 254, in
finish_request
self.RequestHandlerClass(request, client_address, self)
File C:\PROGRA~1\Python25\lib\SocketServer.py, line 521, in __init__
self.handle()
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
httpserver.py, line 432, in handle
BaseHTTPRequestHandler.handle(self)
File C:\PROGRA~1\Python25\lib\BaseHTTPServer.py, line 316, in handle
self.handle_one_request()
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
httpserver.py, line 427, in handle_one_request
self.wsgi_execute()
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
httpserver.py, line 287, in wsgi_execute
self.wsgi_start_response)
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
gzipper.py, line 35, in __call__
return self.application(environ, start_response)
File c:\program
files\python25\lib\site-packages\paste-1.7.1-py2.5.egg\paste\
registry.py, line 350, in __call__
app_iter = self.application(environ, start_response)
File c:\program
files\python25\lib\site-packages\Beaker-1.0.1-py2.5.egg\beake
r\middleware.py, line 74, in __call__
return self.app(environ, start_response)
File c:\program
files\python25\lib\site-packages\Beaker-1.0.1-py2.5.egg\beake
r\middleware.py, line 147, in __call__
return self.wrap_app(environ, session_start_response)
File c:\program
files\python25\lib\site-packages\Routes-1.9.2-py2.5.egg\route
s\middleware.py, line 100, in __call__
response = self.app(environ, start_response)
File c:\my\python\pylons\pylons\wsgiapp.py, line 112, in __call__
to 'return' it?) in: %r % controller.__name__)
Exception: No content returned by controller (Did you remember to
'return' it?)
in: 'PagePublicController'
Re: Debugging failed tests with pylons globals
On Jul 9, 6:22 am, Mike Orr [EMAIL PROTECTED] wrote: Having one SOP, pylons.app, containing all the Pylons globals has long been suggested by me. The value could also be attached to the controller instance -- one attribute instead of several. That would be for users who object to getting request info from a module global, and because I've heard there are some situations (somemod_wsgi applications?) that can't use the SOPs. Not understand what SOPs are all about, can you explain why they would be a problem in mod_wsgi. I keep seeing comments by various people suggesting that they don't really understand how mod_wsgi works. I'd either like to understand what the issue with SOPs is, or if it is a misunderstanding about how mod_wsgi works, then correct that misunderstanding. Thanks. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Debugging failed tests with pylons globals
On Jul 10, 3:12 pm, Mike Orr [EMAIL PROTECTED] wrote: On Wed, Jul 9, 2008 at 7:04 PM, Graham Dumpleton [EMAIL PROTECTED] wrote: On Jul 9, 6:22 am, Mike Orr [EMAIL PROTECTED] wrote: Having one SOP, pylons.app, containing all the Pylons globals has long been suggested by me. The value could also be attached to the controller instance -- one attribute instead of several. That would be for users who object to getting request info from a module global, and because I've heard there are some situations (somemod_wsgi applications?) that can't use the SOPs. Not understand what SOPs are all about, can you explain why they would be a problem in mod_wsgi. I keep seeing comments by various people suggesting that they don't really understand how mod_wsgi works. I'd either like to understand what the issue with SOPs is, or if it is a misunderstanding about how mod_wsgi works, then correct that misunderstanding. I heard somewhere that SOPs don't work with mod_wsgi, and that request/response/session/c et al were also attached to the controller instance because of that. I've never used mod_wsgi so I don't know if it's true or not. The only reference I can find to SOP and mod_wsgi together is a prior comment by you: http://markmail.org/message/wz4yeooo3v3l4ngf Overall there is really nothing special about how mod_wsgi works that would invalidate any specific Python programming techniques. As far as a WSGI application goes, how threading is used should be no different to something like paste server. Since you don't know the reasons why SOPs may be a problem, I'd very much suggest there probably isn't a problem, especially with Ian not really understanding how there would be either. Anyone else know any actual detail about this suggestion that SOPs and mod_wsgi may be a problem. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Adding content-length in all responses
On Jun 18, 12:58 pm, Shannon -jj Behrens [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 4:11 PM, Agustín (Cucho) Villena [EMAIL PROTECTED] wrote: Hi! At work we need to add the content-length header in all our responses, but we don't want to hack any method in our controllers to do that. Is there any way to factor out this behaviour in a single place? Can you use Apache or Nginx to do that for you? In Apache (and with mod_wsgi embedded mode at least, not sure what will happen with daemon mode), provided complete response body is returned in one go from WSGI application, ie., single yield or return array of single string item, then one can enable the Apache CONTENT_LENGTH output filter to add a content length to any response which didn't add its own. Will need to check code and test for daemon mode case, but don't have time right now. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
On Jun 17, 6:55 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Graham Dumpleton wrote: Read: http://code.google.com/p/modwsgi/wiki/ConfigurationIssues Not sure why you want run a single thread. From memory would only want to do that if trying to attach gdb to daemon process and debug at C code level. I tried to run with a single thread for a bit since egg:Paste#evalerror complained it doesnot work in a multi-thread environment, but it turns out it still complains even if you limit mod_wsgi to one thread. Is Paste#evalerror the same as EvalException or something different? Whatever it is, presuming it sees: wsgi.multithread: False in WSGI environment it should be satisfied that it is single threaded. If you can confirm what Python class #evalerror maps to, will have a quick look at what its requirements are. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
On Jun 17, 7:24 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Graham Dumpleton wrote: Is Paste#evalerror the same as EvalException or something different? It's an entry point which maps to paste.evalexception.middleware.make_eval_exception which indeed sets up EvalException. Looking at the code I must have misremembered: it does not support a multi-process environment, but does support multi-threading. Which means that: WSGIDaemonProcess debug alone, ie., allowing default single process to be created, should be sufficient. Note, don't use: WSGIDaemonProcess processes=1 The use of 'processes' option with any number makes mod_wsgi think you have a multiprocess configuration and sets wsgi.multiprocess to be True as a default. Having thus subtle difference was probably not good in hindsight and should have allowed flagging of single process as being part of multi process configuration in a different way. FWIW, you would use 'processes=1' where want only one process on a specific Apache instance, but are loading balancing overall across multiple Apache installations. Need some way in that case to override wsgi.multiprocess so application knows that although only one process in this Apache instance, that may also be running elsewhere. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
Read: http://code.google.com/p/modwsgi/wiki/ConfigurationIssues Not sure why you want run a single thread. From memory would only want to do that if trying to attach gdb to daemon process and debug at C code level. Graham On Jun 16, 3:52 am, Chris [EMAIL PROTECTED] wrote: I've gotten Pylons to successfully run via WSGI on Apache2.2, but only after disabling debugging. Followinghttp://code.google.com/p/modwsgi/wiki/DebuggingTechniques, I've tried to runmod_wsgiin a single thread daemon by appending the lines: WSGIDaemonProcess debug threads=1 WSGIProcessGroup debug to my httpd.conf. However, this completely breaks WSGI, generating the error: [Sun Jun 15 13:44:09 2008] [error] [client 127.0.0.1] (13)Permission denied:mod_wsgi(pid=11972): Unable to connect to WSGI daemon process 'debug' on '/etc/httpd/logs/wsgi.9910.15.1.sock' after multiple attempts. Since there are other applications running through Apache, I can't change the StartServers/ServerLimit params. Is there any other way to enable debugging without lobotomizing Apache? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: advice with configuration/scaling a live Pylons app.
On May 30, 12:56 pm, Mike Orr [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 4:30 PM, Graham Dumpleton [EMAIL PROTECTED] wrote: On May 29, 7:29 pm, Alex Marandon [EMAIL PROTECTED] wrote: 2008/5/29 Alex Marandon [EMAIL PROTECTED]: 2008/5/28 SamDonaldson [EMAIL PROTECTED]: Running ab benchmark tests revealed many requests were failing. Should I be starting MORE Paster processes to handle the load? Is this the right thing to do, or is the Paster (SCGI) process itself multi-threaded to handle such synchronous requests. Say the Paster process is doing some I/O (SQL query through sqlalchemy), would that process block and would other requests wait, or would they get serviced? Hi Sam, According tohttp://wiki.pylonshq.com/display/pylonscookbook/Pylons+Execution+Anal... paster is multithreaded. It should be easy to test. Hit a controller action that sleeps for 10 seconds and see if you can still make requests to other actions. I actually need to test for myself as soon as I get to work. As for why you get failed requests, I don't know. class FooController(BaseController): def bla(self): return 'Hello World! %s' % time.time() def slow_bla(self): time.sleep(10) return 'Hello slow World!' With something like that, manual testing works just fine (ie: I'm able to hit the action bla as many times as I want while the action slow_bla is still serving). When testing with ab though, I do get failed requests, but I actually get even more failed requests with Apache/mod_wsgi. What options are you using to 'ab'? The 'ab' program can give a perception of errors, normally manifesting as lots of exceptions on server side in log file, if you use concurrent requests. This occurs because it only stops when it receives responses for the number of requests you tell it to make. With a request handler that takes a long time, because of a sleep() call, the 'ab' program can actually issue more requests than you tell it to. When it does receive responses for the number you told it, it will simply shutdown the connections for all the additional requests it made which it hasn't yet received a response. The result of this is that on the server side it will see a bunch of closed connections causing failures to be able to write the responses for the additional requests. The end result is that one thinks that the hosting mechanism is having problems, when in fact it is due to how the 'ab' program works. That's akin to the user pressing the Stop button in the browser. I get a connection reset line for that in my Quixote apps but not in my Pylons app. I assumed Pylons just ignored the exceptions because it's not really an error if the client goes away. But in any case, I don't get socket errors in my Pylons error log, and I can't assume that's because nobody ever presses Stop. So if Alex is getting such errors, the question is why the difference in behavior? For mod_wsgi at least, it is a bit pendantic and errs on the side of logging such events on the basis that in some cases it may actually be because of problems in code and/or the user may want to know. There is an issue for mod_wsgi related to this where speculated that it could be made less noisy on such issues where it makes sense: http://code.google.com/p/modwsgi/issues/detail?id=29 and/or whether the messages are displayed dependent on logging levels. At the time it was low priority and haven't since had a chance to get around to looking at it more closely, but will be doing so in next round of code changes. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: advice with configuration/scaling a live Pylons app.
On May 29, 7:29 pm, Alex Marandon [EMAIL PROTECTED] wrote: 2008/5/29 Alex Marandon [EMAIL PROTECTED]: 2008/5/28 SamDonaldson [EMAIL PROTECTED]: Running ab benchmark tests revealed many requests were failing. Should I be starting MORE Paster processes to handle the load? Is this the right thing to do, or is the Paster (SCGI) process itself multi-threaded to handle such synchronous requests. Say the Paster process is doing some I/O (SQL query through sqlalchemy), would that process block and would other requests wait, or would they get serviced? Hi Sam, According tohttp://wiki.pylonshq.com/display/pylonscookbook/Pylons+Execution+Anal... paster is multithreaded. It should be easy to test. Hit a controller action that sleeps for 10 seconds and see if you can still make requests to other actions. I actually need to test for myself as soon as I get to work. As for why you get failed requests, I don't know. class FooController(BaseController): def bla(self): return 'Hello World! %s' % time.time() def slow_bla(self): time.sleep(10) return 'Hello slow World!' With something like that, manual testing works just fine (ie: I'm able to hit the action bla as many times as I want while the action slow_bla is still serving). When testing with ab though, I do get failed requests, but I actually get even more failed requests with Apache/mod_wsgi. What options are you using to 'ab'? The 'ab' program can give a perception of errors, normally manifesting as lots of exceptions on server side in log file, if you use concurrent requests. This occurs because it only stops when it receives responses for the number of requests you tell it to make. With a request handler that takes a long time, because of a sleep() call, the 'ab' program can actually issue more requests than you tell it to. When it does receive responses for the number you told it, it will simply shutdown the connections for all the additional requests it made which it hasn't yet received a response. The result of this is that on the server side it will see a bunch of closed connections causing failures to be able to write the responses for the additional requests. The end result is that one thinks that the hosting mechanism is having problems, when in fact it is due to how the 'ab' program works. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deleting PATH_INFO in WSGI 2
Mike Orr wrote: On Wed, Apr 30, 2008 at 6:21 AM, Ian Bicking [EMAIL PROTECTED] wrote: Yannick Gingras wrote: Ian Bicking [EMAIL PROTECTED] writes: For this particular problem, I can work around the slashes collapsing with a regexp but it would indeed be nice to have a general workaround in WSGI 2. Where is it discussed? Discussion happens on the Web-SIG mailing list, though there hasn't been any discussion lately. There's also the wiki page: http://wsgi.org/wsgi/WSGI_2.0 On the page it says SCRIPT_NAME, PATH_INFO, and QUERY_STRING are recommended for removal. How would url_for() be able to recreate the URL without them? More to the point, how could Routes or Pylons work at all without PATH_INFO: you wouldn't know which controller to route to. And REMOTE_ADDR and SERVER_SOFTWARE: the application may want REMOTE_ADDR for authentication or logging, and SERVER_SOFTWARE is theoretically useful if the app wants to modify its behavior according to the server. Hmmm, I wander if the page is just badly worded. Maybe they meant that 'optional' designation be removed, thereby making them mandatory. Wouldn't be practical not to have them. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deployment Question
On May 21, 5:25 pm, Cliff Wells [EMAIL PROTECTED] wrote: On Tue, 2008-05-20 at 18:13 -0700, Graham Dumpleton wrote: If one really has to use a software proxy, then also perhaps look at dedicated solutions like Pound. It may be the case that nginx serves okay as a proxy, but it isn't purpose built for that and so solutions like Pound may provide a more flexible solution which is easier to configure and manage when load balancing across many machines. I often agree with you in general (despite disagreeing on particular details wink). However you really ought to quit making unfounded generalizations about Nginx. It is, in fact, purpose-built to be a proxy. It's also far better than Pound (which I also used before switching to Nginx) as a proxy. It's true it doesn't (currently) have very sophisticated load-balancing (round-robin only, unless you use a 3rd party module), but it's almost stupidly simple to configure and easily outperforms Pound, especially under load. I stand corrected. I will admit that I am not a nginx, nor even a Pound expert. I would say however that mod_proxy module in Apache is also purpose built for proxying, that doesn't mean it is a good idea to use it. What I was trying to say was that where there are solutions whose only purpose is to do something, also look at them as well as those which may do it as one function of many. This is because the solutions which try to do just the one job do often come with a better feature set for that one task, that depending on what you are doing may make more sense. Yes it may mean a drop in performance for some aspects of the problem being solved, but this may be made up in other ways through the other features it provides. Sorry, I am generalising again of course, but when you really don't know the exact details of what a person is wanting to setup and why, it is hard to do anything else. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deployment Question
On May 22, 5:20 am, Cliff Wells [EMAIL PROTECTED] wrote: Sites that are amongst the largest on the internet fall into a corner case in my mind. As Mike pointed out, sites have an unrealistic expectation of traffic. I've been involved in the average cases. As have I. But I'm going to disassemble this argument below. My claims come from years in the service provider industry, watching various deployments. I've been an Apache fan for a long time, and have seen and deployed hundreds of servers, serving thousands of sites on Apache. I think this is true for all of us. The difference is that the world has changed in the last couple of years and now there's more options to choose from. And by options I don't mean a smaller, less capable Apache clone, I mean a paradigm shift in how to handle high loads. It's well known that threaded/process based servers cannot scale beyond a reasonable point. Nginx and Lighttpd are async and are specifically written to address the C10K problem. There are two approaches one can use for addressing scalability, they are vertical scaling and horizontal scaling. In vertical scaling one just upgrades your existing single machine with a bigger more capable machine. For this path then yes, nginx and lighttpd may give your more head room than Apache. The problem with vertical scaling is cost, plus that you will hit the limit of what the hardware can achieve much sooner than with horizontal scaling. With horizontal scaling you keep your existing machine and just add more machines. For horizontal scaling, the limit is going to be how easy it is to accommodate your application across a growing number of machines. The scalability of Apache here isn't generally going to be an issue as you would have sufficient machines to spread the load so as to not unduly overload a single machine. Although one is buying more hardware with horizontal scaling, the cost/ performance curve would generally increases at a lessor rate than with vertical scaling. This however is tempered by increasing maintenance costs from having to support multiple machines. If machines are all identical though, and treated as an appliance which are either rebuilt or replaced when a failure occurs, even that isn't really a problem. Of course, there is still a whole lot more to it than that as you need to consider power costs, networking costs for hardware/software load balancing, failover and possible need for multiple data centres distributed over different geographic locations. So, what limitations exist and what other issues come into consideration really depend on how you scale up your system. One thing that keeps troubling me about some of the discussions here as to what solution may be better than another is that it appear to focus on what solution may be best for static file sharing or proxying etc. One has to keep in mind that Python web applications have different requirements than these use cases. Python web applications also have different needs to PHP applications. As I originally pointed out, for Python web applications, in general any solution will do as it isn't the network or the web server arrangement that will be the bottleneck. What does it matter if one solution is twice as fast than another for a simple hello world program, when the actual request time saved by that solution when applied to a real world application is far less than 1% of overall request time. For non database Python web applications issues such as the GIL, and how multithreading and/or multiple processes are used is going to be a bigger concern and have more impact on performance. This is in as much as running a single multithreaded process isn't going to cut it when scaling. Thus ease of configuring use of multiple processes is more important as is the ability to recycle processes to avoid issues with increasing memory usage. There is a also the balance between having fixed numbers of processes as is necessary when using fastcgi like approaches, or the ability in something like Apache to dynamically adjust the number of processes to handle requests. Add databases into the mix and you get into a whole new bunch of issues, which others are already discussing. Memory usage in all of this is a big issue and granted that for static file serving nginx and httpd will consume less memory. The difference though for a dynamic Python web application isn't going to be that marked. If you are running a 80MB Python web application process, it is still going to be about that size whatever hosting solution you use. This is because the memory usage is from the Python web application, not the underlying web server. The problem is more to do with how you manage the multiple instances of that 80MB process. There have been discussions over on the Python WEB-SIG about making WSGI better support asynchronous web servers. Part of their rational was that it gave better scalability because it could handle more concurrent
Re: Deployment Question
Cliff Wells wrote: On Tue, 2008-05-20 at 13:49 -0400, Ross Vandegrift wrote: On Mon, May 19, 2008 at 09:10:27PM -0700, Jonathan Vanasco wrote: so is Apache considered to be a good thing (through mod_wsgi , mod_python , or other ?) i've been doing mod_perl dev for years, and have had some experience with mod_python -- generally speaking, my experience is that if you can avoid apache you're better off. i guess that's what is throwing me off. i equate apache with isn't there a better way now? I don't mean to come off as sounding curt, but I've often heard that from people who haven't really maintained the alternatives. Or that have an application that gets deployed in a highly isolated environment, where interoperability means nothing. Using mod_perl as an indicator is actually a bad idea. This is because it tends to be the worst of the bunch when it comes to bloating out Apache. Thus saying that all solutions which embed an interpreter in Apache are bad based on what one sees with mod_perl is not a good idea. The mod_python module does carry a bit more bloat in its base level memory profile than it needs to and this has been identified and discussed on mod_python lists, although nothing down about it yet even though changes relatively simple to address it. The main reason though why mod_python has got a bad reputation for memory usage is threefold. The first is that older versions of mod_python leaked memory. This has been addressed in later versions. The second is that the Python installation being used didn't provide a usable shared library for Python itself and instead there was only a static library. This mean that a static copy of Python was being included in mod_python module. Because of shared library issues this was being converted to local process memory rather than being shared and so base level process sizes were more than they need to. So, install your Python properly and you will avoid this issue. It has also only been the last year or so that Linux distributions have been fixing their Python installations to provide a usable Python shared library. The third reason is simply that Python web applications can get fat, especially when people developing the applications don't take memory usage into consideration at all. Unfortunately people see the large processes sizes caused by their own application, especially when viewed in conjunction with fact that Apache is a multi processor server, and so there are multiple copies, and wrongly think it is mod_python that is causing their problems. Instead it is their own fat application and a lack of understanding of how Apache works and how to configure it so as to limit resource usage. So, although mod_python is at fault a little bit, in the main it is actually factors outside of mod_python. FWIW, mod_wsgi uses even less base level memory than mod_python. As with mod_python, it is still affected by poor Python installations and fat applications being run on it. The mod_wsgi module provides better flexibility however in being able to control memory usage through process recycling. Frankly, the flexability of Apache is what makes it so much better than the alternatives. It has solid support for just about anything related to the web. It has excellent, complete documentation surrounded by a large, knowledgeable user community. I'd qualify this paragraph as some of Apache's strengths are, rather than a blanket it's better. For some people, in some settings, it is better. For others it isn't. If you need high scalability, it isn't the best. If you need a small memory footprint it's not the best. If you prefer a sane configuration syntax it isn't the best. If you need all three then it's arguably amongst the worst. What is silly is people who think that any one web server is going to be the complete solution anyway. One gets truly sick of people asking what is the fastest web server to use as there is so much more to that. Speed does not equate to scalability, and just because one server is fast at serving static files doesn't mean it is good for dynamic web applications. So, servers like nginx and lighttpd will be better than Apache for handling serving of static files. Just because they are though, doesn't mean you should also then use them to host your dynamic web application code. For a Python web site with a requirement to also serve up a lot of static media files, one would definitely want to use a separate nginx or lighttpd server, or even use a specialised CDN. This should be run on its own servers and not on the same server as your web application. As to your dynamic Python code, it would generally be best served as I said before by running Apache prefork MPM with code running directly in Apache processes, ie., embedded mode of mod_wsgi. That server would be dedicated to running just the Python web application code, no static files sharing, no sharing the server with PHP or any
Re: Deployment Question
On May 21, 1:09 am, Jonathan Vanasco [EMAIL PROTECTED] wrote: If you are going to run a large site which is able to respond well to bursts in traffic, running Python embedded in Apache running prefork MPM, with huge amounts of memory in the box is generally the best approach. This is because although memory usage will be high, being non multithreaded you can use any cpu/cores to best advantage, plus you benefit from Apache's ability to create dynamically more processes to handle demand when required and then reap them when no longer required. This is for a startup that will initially have 1pylons + 1 postgres server, and scale out accordingly. They're a video startup, and have some bigger names backing them, so I'd expect them to scale large quickly. However... I have years of experience with mod_perl, and have found the overhead of apache to be nearly worthless. By proxying static stuff off of apache onto nginx, and offloading code portions into nginx/php or twisted, we were able to gain a lot of efficiency. Apache does its job exceedingly well , but its bloated. Also see my comments in other post, but when you say 'proxy' I hope you don't really mean 'proxy'. Although I explained that it is a good idea to off load static media to a separate server, I then really don't understand, as a lot of people do do, why you would also then want to make that static media server the front end and 'proxy' requests for the dynamic web application through it to something else, such as Apache, or even fastcgi processes. All you are doing in doing this is adding additional latency into your requests due to the extra hop. If building a large site and are using a separate media server then use different IPs for each. Preferably this should be a completely different machine. If it has to be the same machine and you can't get additional IPs to allow port 80 to be used for each, then use different ports. If one really has to use a software proxy, then also perhaps look at dedicated solutions like Pound. It may be the case that nginx serves okay as a proxy, but it isn't purpose built for that and so solutions like Pound may provide a more flexible solution which is easier to configure and manage when load balancing across many machines. Better still perhaps is to use hardware based solutions, or DNS features, if needing to load balance across a cluster of machines. Proxying also adds additional overhead even for the fastcgi like case. This is in part why Apache prefork MPM and an embedded solution is better if you want to squeeze out as much performance as possible. That is, the process accepting the connection is the one handling the request, not some backend process it is in turn talking to. Yes you loose ability to run code as a non Apache user, but if the Apache is dedicated to the application, you can make the whole server run as the required user instead of the Apache user anyway, so not an issue. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deployment Question
On May 20, 2:10 pm, Jonathan Vanasco [EMAIL PROTECTED] wrote: so is Apache considered to be a good thing (through mod_wsgi , mod_python , or other ?) i've been doing mod_perl dev for years, and have had some experience with mod_python -- generally speaking, my experience is that if you can avoid apache you're better off. i guess that's what is throwing me off. i equate apache with isn't there a better way now? It really depends on what you want to do. If you are running some small site more or less anything will do as it generally isn't the web server that is your bottleneck. Of course, if you are running in a memory constrained VPS you wouldn't use Apache unless you properly investigate properly how you need to configure it to work under such a constraint. If you are going to run a large site which is able to respond well to bursts in traffic, running Python embedded in Apache running prefork MPM, with huge amounts of memory in the box is generally the best approach. This is because although memory usage will be high, being non multithreaded you can use any cpu/cores to best advantage, plus you benefit from Apache's ability to create dynamically more processes to handle demand when required and then reap them when no longer required. In other words, it is impossible to answer you question without really knowing what your site is doing, how big it is, amount of traffic etc etc. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Multiple Pylons instances, processor affinity, and threads
On Apr 25, 4:59 am, Devin Torres [EMAIL PROTECTED] wrote: Use Apache and mod_wsgi and you have all that you want except playing with 'processor affinity'. This is because Apache is multi process by design and thus can properly make use of multiple CPUs. A lot of what goes on in Apache is also not implemented in Python and thus not subject to GIL issues. You might also have a read of the following: http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modws... http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html Read. Apache is starting to look attractive now. So I assume I'm not looking for embedded mode, right? You say it's more performance, but at the cost of what? Using the worker MPM and, say, daemon-mode, using, say, 4 processes and 16 threads each, would my processes be dying as soon as they're not needed? My application takes awhile to load because I autoload my database using SQLAlchemy. Is it that easy to configure apache to start 4 by default and load balance between all of them? If you are running a web site that requires the absolute best performance possible, you would dedicate the Apache instance to running just the one Python web application. That Apache instance would be setup to use prefork MPM and you would use mod_wsgi embedded mode. You would turn off keep alive for the Apache instance. You would throw as much memory as possible into the system and you would use a dedicated machine and not a VPS. At the same time, all static media would be served from a distinct nginx or lighttpd instance or via a content delivery provider. The static media server would still use keep alive. A typical default Apache prefork configuration is: IfModule mpm_prefork_module StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 /IfModule That is, initially create 5 child processes for serving requests. To support maximum 150 clients at a time, because each child process is single threaded, it can theoretically create up to 150 child processes to handle requests, if demand so requires. As demand drops off and process become unused, it will start to kill of additional child processes, when this occurs it will keep arise between 5 and 10 of these additional servers as spares for future bursts in traffic. Apart from where it creates additional process to meet demand and then kills them off when no longer required, the child process will be kept around for ever. This is because max requests per child is set to 0. If you had a problem with memory creep in an application, you could set max requests per child to some non zero number and child processes would be recycled after than number of requests. Now, depending on how expensive loading the application is initially and what you expected traffic volume is, you would customise these values to keep as many persistent child processes around as possible to meet average demand, plus some measure of bursts in traffic. What the values would be you would have to experiment with. Anyway, that is the extreme end where performance is the most important thing. In this case you would use prefork MPM and mod_wsgi embedded mode. The other extreme end is a memory constrained system, in which case you would use worker MPM, with small number of initial Apache child processes, plus use mod_wsgi daemon mode with single daemon process with limited number of threads. Static media would be served on same Apache instance. The limited number of threads would be to minimise possibility of memory blowing out due to multiple concurrent requests allocating a lot of transient memory at the same time. To temper this one would set maximum number of requests for a process and set inactivity timeouts so that daemon processes recycled if not doing anything, thus bring memory back to minimal levels. Apache, through which MPM you use and how you configure it, plus mod_wsgi and whether you use embedded mode or daemon mode, plus how you configure daemon mode, provide a great deal of flexibility in creating a setup anywhere between these extremes. What configuration is going to be best really depends on a lot of different issues, many of which you don't expand on, such as how important is performance, how much memory is available, how much memory your applications require etc etc etc. Even when you think you have a good idea of what sort of configuration will work, you need to then properly test it, as well as compare that performance to alternate configurations. Personally I'd probably just suggest you start out with mod_wsgi embedded mode with either prefork or worker MPM and just see how it goes and get a feel for how Apache works, especially with respect to it use of multiple processes to handle requests. For most peoples web site applications, the configuration doesn't generally matter that much as there application never has high
Re: Multiple Pylons instances, processor affinity, and threads
On Apr 24, 3:51 am, Devin Torres [EMAIL PROTECTED] wrote: So we're using Pylons and Python in general for our new company platform. We just bought a server with 4 cores to help us reach our scalability goals, but there are a few questions I'm interested in asking the Pylons community. I (mostly) understand the nature of threads in Python. From my understanding, the GIL locks the interpreter to executing only one Python thread at a time, but C modules can take advantage of a Python application being multithreaded, because they can operate independant of the GIL. Presumably, this would mean that there is, in fact, a benefit to using threads in Paste, because most network I/O bound stuff happens within a C module. Given this situation, I believe that despite paste making an effort to be multithreaded, it would still be advantageous to run a cluster of four Pylons instances and proxy to these using nginx. Using our setup we'd have four pylons instances being proxied to by four nginx worker threads. In nginx you can set the processor affinity for each worker thread, thus placing each worker on a different core 0..3. Here's where things get tricky: I've found a Python package that apparently allows Python applications to set their processor affinity (I'm afraid it doesn't work on OS X):http://pypi.python.org/pypi/affinity/0.1.0 Using this, what do you guys thing on my idea to write a custom cluster controller, perhaps using supervisord, that will start nginx and the four worker processes, and then fork()'s my Pylons app into into a cluster of four? Is this overkill? Is Paste more mulithreaded than I'm giving it credit for? Is there a better way to go about this? Does an alternative to the 'affinity' package exist? Use Apache and mod_wsgi and you have all that you want except playing with 'processor affinity'. This is because Apache is multi process by design and thus can properly make use of multiple CPUs. A lot of what goes on in Apache is also not implemented in Python and thus not subject to GIL issues. You might also have a read of the following: http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html These explain some of these issues about multiprocess web servers and the GIL. Not sure why you just wouldn't let the operating system handle allocation of processes/threads across CPUs as it is likely in general to do a better job. Are you sure you aren't trying to solve a problem that doesn't really exist. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: EvalExceptions with apache
Also read section 'Browser Based Debugger' of: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques to find out why you had the problem in the first place. Graham On Apr 20, 4:32 am, petr kobalicek [EMAIL PROTECTED] wrote: I have probabbly solved this by using: set debug = false interesting :) 2008/4/19, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi, I'm testing my pylons application with apache and I have one problem. Sometimes it sends me internal server error (500) and in apache log is AssertionError: The EvalExceptions middleware is not usable in a multi- process environment. I don't know how to solve this problem, because i have turned debugging off in config file: debug = false full_stack = false Have anybody this problem too ? Or how can I solve this ? Note: I'm using devel version of pylons with gentoo linux (apache is configured properly I hope). Thank you for reply --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Are you going to convert Pylons code into Python 3000?
Jose Galvez wrote: this is an interesting issue, because I would suspect that all our pylons applications will have to be converted as well as the pylons base code. I know that there is going to be a program which will automate the translation, but not having used it I don't know what issues the translation will cause. The other big question is will eggs will they be able to tell the difference between python 2.x and 3.x since the code will be different Jose On Tue, Mar 4, 2008 at 3:17 AM, Leo [EMAIL PROTECTED] wrote: Subj. Is Python 3000 migration planned? There is more to it than just that. One problem is that the WSGI 1.0 specification is incompatible with Python 3.0. There were some preliminary discussions about how the specification would need to be changed, but no real final outcome. The discussions also probably didn't cover everything that would need to be changed in the specification. For example, wsgi.file_wrapper and how it would have to be changed wasn't discussed. The main issues were captured in: http://www.wsgi.org/wsgi/Amendments_1.0 Note though that that page is merely a collection of points discussed and is itself not any sort of official set of amendments to the WSGI specification. Personally I believe that WSGI 1.0 should die along with Python 2.X. I believe that WSGI 2.0 should be developed to replace it and the introduction of Python 3.0 would be a great time to do that given that people are going to have to change their code anyway and that code isn't then likely to be backward compatible with Python 2.X. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: [Web-SIG] Are you going to convert Pylons code into Python 3000?
On 05/03/2008, Martijn Faassen [EMAIL PROTECTED] wrote: Hey, On Wed, Mar 5, 2008 at 12:05 AM, Graham Dumpleton [EMAIL PROTECTED] wrote: [snip] Personally I believe that WSGI 1.0 should die along with Python 2.X. I believe that WSGI 2.0 should be developed to replace it and the introduction of Python 3.0 would be a great time to do that given that people are going to have to change their code anyway and that code isn't then likely to be backward compatible with Python 2.X. I think lots of Python projects reason this way: Python 3 transition is the right time to break backwards compatibility in our library/framework. It's understandable. Unfortunately this means that for people adjusting their code, they won't just have to deal with the large Python 3 transition, but also with lots of their frameworks and libraries making backwards-incompatible changes. That's unfortunate, as that means any automatic conversion strategy using the py2to3 script won't be possible, and there won't be any way to keep libraries in transition working in both Python 2 and 3 for a while (which is Guido's plan), as their dependencies don't support it. In the case of code which directly talks to the interface defined by WSGI specification I very much doubt the py2to3 script will help. This is because for WSGI to work with Python 3.0 there needs to be a change from use of string type objects to byte string type objects. I would suspect that py2to3 is only get help in any sort of automated way with the fact that a string object becomes unicode aware, not where with WSGI the code would have to change to use and deal with a different type of object completely. The implications of this change to a byte string type object are going to be much more complicated. What I fear is that if Python 3.0 isn't used as a trigger to push out WSGI 2.0, we will end up being stuck with WSGI 1.0 forever and there will never ever be any momentum to updating it even though a range of deficiencies and shortcomings have been identified in the specification as far as the way it is drafted, with the functionality it provides and how that functionality is described as needing to be implemented. I'd rather not see another XML-RPC where in practice it was a good first attempt, but with a little bit of tweaking would have made it so much better, but still keep its simplicity. And no I don't mean SOAP, that went too far. Problem with XML-RPC from what I saw at the time is that the original author had a lot invested in software that used the original XML-RPC and he wasn't going to budge as he didn't want to have to change his own systems based on it. With Python 3.0 people are going to have to change their code anyway and so it is an ideal time to push to a new version of WSGI specification which fixes its warts and eliminates the oddities it had to support certain legacy systems, something which is now not seen as necessary. Also, for most systems that use WSGI it would be quite minimal impact, as they often use it merely as a bridge to some existing web server interface. Thus changes would be very localised. Even something like Paste/Pylons hides a lot of what is WSGI behind its own veneer, for example WebOb and its predecessor and so higher layers may not even be affected much. As much as I'd like to see everything move to a better WSGI 2.0, if there are components which people don't want to update, then a WSGI 2.0 to 1.0 bridging middleware can be used to adapt them. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: how do i create a custom internal server error page? .htaccess?
On Feb 21, 1:40 pm, johnnyice [EMAIL PROTECTED] wrote: Hi! When I turn debug to false and there is a problem with my code I am redirected to a blank page that reads internal server error. okay, that is supposed to happen... but I want my chrome around that. usually i would just define a line in my .htaccess file and point it to the page I want to display. however i don't know if htaccess is appropriate nor where to put it (I tried /public and a couple other folders and nothing seems to pick up). It possibly depends on which level in the WSGI stack or underlying WSGI adapter for the web server you are using to host your application that generates the page. Am sure Pylons probably has an inbuilt mechanism for providing customised error pages and someone else will no doubt point you to that, but in terms of generic WSGI applications the following would apply. If somewhere down in the WSGI stack is capturing the exception and generating a complete 500 response including response content, then you would need to introduce a middleware component that detects that 500 response and changes it as it is passed up. If the exception isn't being caught and is instead propagating right back up to the WSGI server adapter and it is that which is generating the 500 response, then you would use a middleware component that catches the exception and generates a complete 500 response of its own from scratch. A more tricky situation although not likely to occur for your case, is where for some reason an error occurs within the WSGI adapter itself and it generates its own complete 500 response for that error. Because there is no user code between it and the web client, it is much harder to intercept and modify it. One possibility here though is if you are running behind mod_proxy. In that case you can intercept it in Apache by setting ProxyOverrideError to On. Doing this will result in appropriate error responses being redirected internally by Apache to the page appropriate for the ErrorDocument URL for that error status, thus allowing it to replace the error page. This is useful where you need to make error pages consistent across many applications being fronted by the one Apache. Because it is being handled in Apache though, you loose access to any context information such as stack traces which would be available to the WSGI application itself. Not even sure you get access to the original error response content as that is most likely discarded. To help answer the question you may want to be clearer about whether you are using Paste serve and/or mod_proxy. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Issues running Pylons with mod_wsgi on Windows
On Jan 19, 8:25 am, Localhost [EMAIL PROTECTED] wrote:
David,
You need to run the command 'python setup.py develop' (no quotes) in
the directory: C:\Program Files\Python25\Scripts\helloworld\ since
Python is unable to find the directory where helloworld is located.
This should help.
That shouldn't be required as the sys.path.append() done in the WSGI
script file should be sufficient for Python running under mod_wsgi to
find it. In other words, there should not be a need to install a
reference in the site-packages directory.
That said, it has been seen for whatever reason on a couple of
occasions that a brand new application created with paster create just
doesn't want to work and one gets that error. It only happens rarely
and in trying to reproduce the problem it hasn't occurred. One trick
used before was to run paster serve just once for the application and
then it would work okay under mod_wsgi.
So, there is definitely something odd going on whereby something isn't
set up reliably when using virtual environments.
Graham
On Jan 18, 3:00 pm, David [EMAIL PROTECTED] wrote:
The helloworld app was created by the pylons script.. I forgot what
it's called.. that creates new applications. The egg cache directory,
to be sure it was writable, has full control given to the Everyone
group.
Here's my wsgi script:
import os, sys
sys.path.append('C:/Program Files/Python25/Scripts/helloworld')
os.environ['PYTHON_EGG_CACHE'] = 'C:/Program Files/Python25/egg-cache'
from paste.deploy import loadapp
application = loadapp('C:/Program Files/Python25/Scripts/helloworld/
development.ini')
Here's my apache error:
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]mod_wsgi
(pid=484): Target WSGI script 'C:/Program Files/Python25/Scripts/
helloworld/wsgi/myapp.wsgi' cannot be loaded as Python module.
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]mod_wsgi
(pid=484): Exception occurred processing WSGI script 'C:/Program Files/
Python25/Scripts/helloworld/wsgi/myapp.wsgi'.
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] Traceback (most
recent call last):
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File C:/
Program Files/Python25/Scripts/helloworld/wsgi/myapp.wsgi, line 10,
in module
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] application
= loadapp(config: + APP_CONFIG)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 193, in loadapp
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] return
loadobj(APP, uri, name=name, **kw)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 213, in loadobj
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]
global_conf=global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 237, in loadcontext
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]
global_conf=global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 267, in _loadconfig
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] return
loader.get_context(object_type, name, global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 393, in get_context
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] section)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 415, in _context_from_use
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] object_type,
name=use, global_conf=global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 345, in get_context
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]
global_conf=global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 237, in loadcontext
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1]
global_conf=global_conf)
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] File c:\
\program files\\python25\\lib\\site-packages\\pastedeploy-1.3.1-
py2.5.egg\\paste\\deploy\\loadwsgi.py, line 274, in _loadegg
[Fri Jan 18 14:58:47 2008] [error] [client 127.0.0.1] return
Re: Issues running Pylons with mod_wsgi on Windows
On Jan 17, 2:43 pm, David [EMAIL PROTECTED] wrote: The article I've been working from is:http://wiki.pylonshq.com/display/pylonscookbook/mod_wsgi+and+workinge... It seems to be the simplest route, though I can't get it to work properly. Through the step where I verify mod_wsgi works, which it does, everything is OK. When I move on to the startup script and the activate_workingenv.py script, I start getting a 500 error. I'd suggest as a start using the following documentation instead: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/VirtualEnvironments That workingenv example is more complicated than it needs to be. The virtual environments documentation on mod_wsgi web site shows more minimal solution. If you cannot get it working with these other instructions, show the contents of your WSGI script file. Graham I've pasted the error log lines from Apache below. I've tried to isolate the issue but can't seem to peg the exact problem. It seems like there is an issue importing from Paste . I do have Paste and PasteDeploy installed, verified with easy_setup - and I can run Pylons apps w/ Paste from command line anyway. Unless I'm reading it wrong, it seems like the import of pkg_resources is where the trouble starts. pkg_resources is part of setuptools which I do have installed. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] mod_wsgi (pid=5224): Target WSGI script 'C:/Program Files/Python25/Scripts/ helloworld/wsgi/myapp.wsgi' cannot be loaded as Python module. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] mod_wsgi (pid=5224): Exception occurred processing WSGI script 'C:/Program Files/Python25/Scripts/helloworld/wsgi/myapp.wsgi'. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] Traceback (most recent call last): [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:/ Program Files/Python25/Scripts/helloworld/wsgi/myapp.wsgi, line 9, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] from paste.deploy import loadapp [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File c:\ \program files\\python25\\lib\\site-packages\\pastescript-1.3.6- py2.5.egg\\paste\\__init__.py, line 4, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] import pkg_resources [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 2552, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] working_set = WorkingSet() [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 384, in __init__ [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] self.add_entry(entry) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 399, in add_entry [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] for dist in find_distributions(entry, True): [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 1614, in find_distributions [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] importer = get_importer(path_item) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\pkgutil.py, line 376, in get_importer [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] importer = path_hook(path_item) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] TypeError: zipimporter() argument 1 must be string, not module --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Issues running Pylons with mod_wsgi on Windows
Oh, also just noticed you are using Windows. In that case also keep an eye on discussion: http://groups.google.com/group/modwsgi/browse_frm/thread/15145cc2d0a12f02 The recipe on virtual environments referenced may need some tweaking for Windows if wanting to use WSGIPythonHome to create an isolated Python base environment. We are trying to sort out if it does or not at the moment. If you don't need an isolated base environment, remainder of recipe probably fine. Graham On Jan 17, 4:46 pm, Graham Dumpleton [EMAIL PROTECTED] wrote: On Jan 17, 2:43 pm, David [EMAIL PROTECTED] wrote: The article I've been working from is:http://wiki.pylonshq.com/display/pylonscookbook/mod_wsgi+and+workinge... It seems to be the simplest route, though I can't get it to work properly. Through the step where I verify mod_wsgi works, which it does, everything is OK. When I move on to the startup script and the activate_workingenv.py script, I start getting a 500 error. I'd suggest as a start using the following documentation instead: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/VirtualEnvironments That workingenv example is more complicated than it needs to be. The virtual environments documentation on mod_wsgi web site shows more minimal solution. If you cannot get it working with these other instructions, show the contents of your WSGI script file. Graham I've pasted the error log lines from Apache below. I've tried to isolate the issue but can't seem to peg the exact problem. It seems like there is an issue importing from Paste . I do have Paste and PasteDeploy installed, verified with easy_setup - and I can run Pylons apps w/ Paste from command line anyway. Unless I'm reading it wrong, it seems like the import of pkg_resources is where the trouble starts. pkg_resources is part of setuptools which I do have installed. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] mod_wsgi (pid=5224): Target WSGI script 'C:/Program Files/Python25/Scripts/ helloworld/wsgi/myapp.wsgi' cannot be loaded as Python module. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] mod_wsgi (pid=5224): Exception occurred processing WSGI script 'C:/Program Files/Python25/Scripts/helloworld/wsgi/myapp.wsgi'. [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] Traceback (most recent call last): [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:/ Program Files/Python25/Scripts/helloworld/wsgi/myapp.wsgi, line 9, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] from paste.deploy import loadapp [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File c:\ \program files\\python25\\lib\\site-packages\\pastescript-1.3.6- py2.5.egg\\paste\\__init__.py, line 4, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] import pkg_resources [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 2552, in module [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] working_set = WorkingSet() [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 384, in __init__ [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] self.add_entry(entry) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 399, in add_entry [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] for dist in find_distributions(entry, True): [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\site-packages\\pkg_resources.py, line 1614, in find_distributions [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] importer = get_importer(path_item) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] File C:\ \Program Files\\Python25\\lib\\pkgutil.py, line 376, in get_importer [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] importer = path_hook(path_item) [Wed Jan 16 21:19:10 2008] [error] [client 127.0.0.1] TypeError: zipimporter() argument 1 must be string, not module --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons as a WSGI application under Apache
On Jan 4, 6:02 pm, artyom.shalkhakov [EMAIL PROTECTED]
wrote:
Hello,
I've tried to run Pylons as a WSGI application using apache2.2 and
mod_wsgi2.0.
So far simple 'hello world' applications work fine (Pylons through
paste serve works okay, too).
When I try to run Pylons under mod_wsgi, I get the following error:
[Fri Jan 04 12:36:00 2008] [error] [client 127.0.0.1]
DistributionNotFound: mysite.com
The app.wsgi looks like this:
from paste.deploy import loadapp
# yes, everything is under my home directory
application = loadapp('config:development.ini', relative_to='home/
artyom/public_html/mysite.com/')
What can be wrong here?
Run your application once using 'paster serve' before trying to run it
under mod_wsgi.
I haven't looked into what 'paster serve' does yet, but it seems to do
some once off initialisation to set up the site directories properly.
There is possibly some other command which will do the same thing
rather than you actually have to run up the server itself.
I was going to investigate and document this, but got side
tracked. :-)
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Pylons as a WSGI application under Apache
On Jan 5, 11:46 am, Ian Bicking [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
On Jan 4, 6:02 pm, artyom.shalkhakov [EMAIL PROTECTED]
wrote:
Hello,
I've tried to run Pylons as a WSGI application using apache2.2 and
mod_wsgi2.0.
So far simple 'hello world' applications work fine (Pylons through
paste serve works okay, too).
When I try to run Pylons under mod_wsgi, I get the following error:
[Fri Jan 04 12:36:00 2008] [error] [client 127.0.0.1]
DistributionNotFound: mysite.com
The app.wsgi looks like this:
from paste.deploy import loadapp
# yes, everything is under my home directory
application = loadapp('config:development.ini', relative_to='home/
artyom/public_html/mysite.com/')
What can be wrong here?
Run your application once using 'paster serve' before trying to run it
under mod_wsgi.
I haven't looked into what 'paster serve' does yet, but it seems to do
some once off initialisation to set up the site directories properly.
There is possibly some other command which will do the same thing
rather than you actually have to run up the server itself.
I was going to investigate and document this, but got side
tracked. :-)
It doesn't do much. The logging stuff has some customizations (in
paste.script.util.logging_config), but I must admit I don't know quite
what they are about; Philip Jenvy did those.
This sounds like something to do with the actual application loading
(any logging stuff isn't being loaded at all). paster serve really
doesn't do much there. It adds 'config:' to the start of the config
file if you don't give it, and can take an explicit app name/section
argument (instead of #section) and passes that as the 'name' keyword to
loadapp. But that's it. It might be hard to see in all the
daemonization, reloading, etc stuff in paster serve, but the actual
loading and serving of apps is just a very small bit of code.
Out of curiosity, I grabbed the original version of the command (just
the implementation) before it grew so large:
def command(self):
app_spec = self.args[0]
app_name = self.options.app_name
if not self._scheme_re.search(app_spec):
app_spec = 'config:' + app_spec
server_name = self.options.server_name
if self.options.server:
server_spec = 'egg:PasteScript'
assert server_name is None
server_name = self.options.server
else:
server_spec = app_spec
base = os.getcwd()
server = loadserver(server_spec, name=server_name,
relative_to=base)
app = loadapp(app_spec, name=app_name,
relative_to=base)
server(app)
Hmmm, odd. I tried a fresh new site and didn't have the same problem
as OP this time, not needing to run paster serve first to make it
work. The only difference was that this was the second site created
from the virtualenv setup I was using.
Certainly something odd going on as I know I saw the problem for first
site created against this virtualenv setup. I'll definitely have to
dig into it later when I get a chance.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Pylons as a WSGI application under Apache
On Jan 5, 12:55 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
On Jan 5, 11:46 am, Ian Bicking [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
On Jan 4, 6:02 pm, artyom.shalkhakov [EMAIL PROTECTED]
wrote:
Hello,
I've tried to run Pylons as a WSGI application using apache2.2 and
mod_wsgi2.0.
So far simple 'hello world' applications work fine (Pylons through
paste serve works okay, too).
When I try to run Pylons under mod_wsgi, I get the following error:
[Fri Jan 04 12:36:00 2008] [error] [client 127.0.0.1]
DistributionNotFound: mysite.com
The app.wsgi looks like this:
from paste.deploy import loadapp
# yes, everything is under my home directory
application = loadapp('config:development.ini', relative_to='home/
artyom/public_html/mysite.com/')
What can be wrong here?
Run your application once using 'paster serve' before trying to run it
under mod_wsgi.
I haven't looked into what 'paster serve' does yet, but it seems to do
some once off initialisation to set up the site directories properly.
There is possibly some other command which will do the same thing
rather than you actually have to run up the server itself.
I was going to investigate and document this, but got side
tracked. :-)
It doesn't do much. The logging stuff has some customizations (in
paste.script.util.logging_config), but I must admit I don't know quite
what they are about; Philip Jenvy did those.
This sounds like something to do with the actual application loading
(any logging stuff isn't being loaded at all). paster serve really
doesn't do much there. It adds 'config:' to the start of the config
file if you don't give it, and can take an explicit app name/section
argument (instead of #section) and passes that as the 'name' keyword to
loadapp. But that's it. It might be hard to see in all the
daemonization, reloading, etc stuff in paster serve, but the actual
loading and serving of apps is just a very small bit of code.
Out of curiosity, I grabbed the original version of the command (just
the implementation) before it grew so large:
def command(self):
app_spec = self.args[0]
app_name = self.options.app_name
if not self._scheme_re.search(app_spec):
app_spec = 'config:' + app_spec
server_name = self.options.server_name
if self.options.server:
server_spec = 'egg:PasteScript'
assert server_name is None
server_name = self.options.server
else:
server_spec = app_spec
base = os.getcwd()
server = loadserver(server_spec, name=server_name,
relative_to=base)
app = loadapp(app_spec, name=app_name,
relative_to=base)
server(app)
Hmmm, odd. I tried a fresh new site and didn't have the same problem
as OP this time, not needing to run paster serve first to make it
work. The only difference was that this was the second site created
from the virtualenv setup I was using.
Certainly something odd going on as I know I saw the problem for first
site created against this virtualenv setup. I'll definitely have to
dig into it later when I get a chance.
The problem I saw may actually have been something totally different
as I note the OP uses:
application = loadapp('config:development.ini', relative_to='home/
artyom/public_html/mysite.com/')
whereas I don't use relative_to and instead use just the 'config:'
string with a full path.
What does the relative_to option do?
Maybe the sys.path suggested by someone else was all that was wrong.
Need to know for sure if that was the OPs complete WSGI application
script file. The instructions at:
http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons
show the need for the sys.path setup, but was that actually done, or
does this relative_to option somehow cause a problem?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Pylons in production
On Jan 4, 6:14 am, Matt Haggard [EMAIL PROTECTED] wrote: Thank you Graham, I'll look into mod_wsgi -- that looks very promising. I have another follow-up question about multiple-app design -- and I'll give the whole story so it makes sense where I'm coming from: Currently, we have one big database with many tables, then a mess of pages that do various functions (I think this is pretty typical of many websites). We're moving to a MVC approach because it seems to make more sense (routes/orm/etc). Now I'm having trouble deciding what to split into separate apps, what to split into controllers, how to share models/templates/static files between the apps. I've just gotten to the point that I have (working) common directories for templates, template filters, models and static files. But upon reaching that point, I step back and wonder, Does it make more sense to combine these apps into a single app with several controllers? Am I completely misusing the Pylons model? For instance... 1) Every app will require authentication - which is based on the users table in the (common) database... and I import user.py (from the common model dir) for that purpose. 2) Every app will use the same db. That means that I can't run (or can I?) an app by itself, because it requires a db that resides up a level. I guess my question boils down to (at least in part): Should an app be a standalone app? If you want process separation for parts of your application but don't quite know if they should be split into actual separate applications, mod_wsgi still allows you to delegate just parts of an application to distinct daemon processes without breaking apart the code for the application. For example, you might have: WSGIScriptAlias / /some/path/thewholeapplication.py which maps to single .ini file for Pylons which may or may not use composition to binding multiple applications together. Using WSGIDaemonProcess/WSGIProcessGroup/Location directives as shown previously, you can arbitrarily delegate certain URL or subsets of URLs to different processes. For example, irrespective of application lines, imagine that you had certain URLs which did a lot of PDF file generation on the fly using reportlab and because of what was being done it would take up lots of memory whereas other parts of the application don't. You could delegate just those URLs to be handled in their own daemon process and then set a low number of maximum requests for that process so that it is recycled on a regular basis to reclaim memory. You could also set an inactivity timeout so that it is recycled if no requests received for a period. Thus: # Run main Pylons application in Apache child process for best performance. # The default configuration results in that happening so nothing to do except # mount the application on root. WSGIScriptAlias / /some/path/thewholeapplication.py # Create a daemon process for memory hungry PDF generation code. WSGIDaemonProcess memory-hungry-pdfs threads=5 maximum-requests=50 inactivity-timeout=30 # Delegate the memory hungry PDF URLs to the daemon process. Location /memory/hungry/urls/root WSGIProcessGroup memory-hungry-pdfs /Location Thus, rather than all processes being used for your main application being bloated out by the memory hungry parts of an application, you can isolate that stuff an keep overall memory down. The only issue in respect of your original goals about code reloading is that because there aren't separate application script files you can't just touch a script file for a specific application and have it be restarted. In the example above I put the main part of the application in the Apache child processes anyway, which ould required a full Apache restart to reload main part of application. To force reloading of memory hungry URL process, then you need to work out the pid and send it a SIGINT. The pid would be identified from Apache error log messages provided that LogLevel set to info. Reason pid is found in that way is that it still shows as 'httpd' process and so if all running as Apache user you can tell it is the daemon process from 'ps'. One feature of daemon processes is that one can make process run as distinct user. This would allow it to be easily identified in ps output, but more importantly you could run different parts of your application code as different users as well if they have special access requirements. Anyway, few more ideas for you there. :-) Graham On Jan 2, 8:47 pm, Graham Dumpleton [EMAIL PROTECTED] wrote: On Jan 3, 5:14 am, Matt Haggard [EMAIL PROTECTED] wrote: I'm (in the process of) using pylons in a production environment and still have a few questions: 1) Do I really have to restart the server every time I make a change (controller/model)? I can foresee making many changes and some which require immediate attention, but restarting the server in the middle of the day would not be an option
Re: Pylons in production
On Jan 3, 5:14 am, Matt Haggard [EMAIL PROTECTED] wrote:
I'm (in the process of) using pylons in a production environment and
still have a few questions:
1) Do I really have to restart the server every time I make a change
(controller/model)? I can foresee making many changes and some which
require immediate attention, but restarting the server in the middle
of the day would not be an option. So, do I have to make changes at
night? Is there no way for the server to adopt the changes without
killing all connections?
2) The system will be composed of multiple apps... (perhaps as many as
20 or more) so would it be better (if I need to restart after every
change) to have all the apps served by their own servers? I mean, is
it better to have 20 instances of the paster server if uptime is such
a priority?
3) In serving several apps (thanks to Ian Bicking for the help to get
that going!) like this:
[composite:main]
use = egg:Paste#urlmap
/ = config:home_app/development.ini
/app2 = config:app2/development.ini
...
how do I make app2 aware that all of his urls are based off of /app2?
well... actually, it is already aware of that. I'm really asking: Is
there a way for app2 to know that the home directory is just
plain / ? This comes up because I use a shared repository for images
and when I reference images from app2 with src=images/something.jpg
it looks for the image at the
urlhttp://127.0.0.1:5000/app2/images/something.jpg
instead ofhttp://127.0.0.1:5000/images/something.jpg. Also, I'd like
for app2 to be able to link back to / without explicitly hard-coding
that url (I can see in the future bumping everything up a directory...
making / into /section and /app2 into /section/app2)
Am I just going about this the wrong way?
Many Pylons folks have an aversion to mod_wsgi and will refuse to use
it on religious grounds without even trying it, but the problems you
are trying to solve are exactly the sort of the things that mod_wsgi
is really good for. This is because mod_wsgi handles both the restart
case as well as the problem of splitting up a monolithic application
to run across multiple distinct processes. The steps required to do
this are relative easy and don't require having to setup lots of
distinct server instances each with a supervisor system as Apache/
mod_wsgi will handle that all for you automatically.
Starting with separation of applications into distinct processes to
allow them to be individually restart, one would take your composite
application and create separate .ini files for each application. One
would just then mount them as separate WSGI applications. For example:
WSGIScriptAlias /app2 /some/path/app2.wsgi
WSGIScriptAlias / /some/path/home_app.wsgi
Leave it like that and all you have done is separated the applications
so that they run within distinct sub interpreters in the same
processes. Add daemon processes to the mix though and you can delegate
each to run in a separate process and/or processes.
WSGIDaemonProcess app2 threads=25
WSGIScriptAlias /app2 /some/path/app2.wsgi
Location /app2
WSGIProcessGroup app2
WSGIReloadMechanism Process
/Location
WSGIDaemonProcess home_app threads=25
WSGIScriptAlias / /some/path/home_app.wsgi
Location /
WSGIProcessGroup home_app
WSGIReloadMechanism Process
/Location
Each application now runs in a separate process with 25 threads.
Having enabled process reload mechanism available with mod_wsgi 2.0,
to restart an application all you need to do is touch (ie., change
modification time) of the WSGI script file for that application and it
wll be automatically restarted prior to next request it receives. The
restart of that application doesn't affect other applications not
require Apache as a whole to be restarted.
The contents of those WSGI script files is pretty trivial and just
setup the WSGI application entry point.
import os, sys
sys.path.append('/usr/local/pylons/home_app')
from paste.deploy import loadapp
application = loadapp('config:/usr/local/pylons/home_app/
development.ini')
Although relatively easy to setup, it should do pretty well what you
want.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: mod_wsgi and pylons, Logging
Sorry, got myself confused, where I said CustomLog I meant ErrorLog.
Can you summarise what works and doesn't for basic use case inside a
hello world application. Ie., what gets output to Apache error log
(and which one) for the following:
import sys
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
print sys.stderr, sys.stderr
print environ[wsgi.errors], wsgi.errors
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
This will tell me if we are talking about an underlying mod_wsgi
issue, or something specific to how Pylons does logging.
Note that LogLevel directive in Apache must be at least 'error' for
either of these to be displayed. Generally the default is 'warn' which
should capture them.
If both of those works in both embedded and daemon mode, but a Pylons
specific application is not generating anything to error log when you
expect it, can you give a small example which would demonstrate the
problem.
Thanks.
Graham
On Dec 20, 5:41 pm, Jeff Lindsay [EMAIL PROTECTED] wrote:
Ok, that makes sense now but only concerns me more because logging in
daemon mode is not working, using wsgi.errors or sys.stderr. However,
I'm a bit confused because CustomLog is used for access logs, which
does work btw if I wasn't clear. It's only error logs that don't work.
-jeff
On Dec 19, 2007 9:47 PM, Graham Dumpleton [EMAIL PROTECTED] wrote:
I am only referring to anything output directly via sys.stderr.
Any messages output via wsgi.errors passed in the WSGI environment,
which is how most WSGI application would tend to log, would go to the
log file associated with the context the request is handled in. If you
have a CustomLog in a VirtualHost container, then that is where those
messages would go. Any error messages generated by mod_wsgi, including
error tracebacks, which correspond to a specific request will
similarly be output to the error log file associated with the
VirtualHost if CustomLog is used.
The case which differs is when using sys.stderr directly, or where
using the logging module since it defaults to using sys.stderr also.
Because sys.stderr is global to the interpreter it isn't associated
with a specific request and so cannot normally be associated with the
custom log of the virtual host. This is the case because technically
it is possible for requests against different virtual hosts to be
directed to the same interpreter instance.
Daemon mode, where WSGIDaemonProcess is used inside of a VirtualHost,
is a special case because in that scenario, that the directive appears
inside of the VirtualHost means that only requests bound for that
virtual host could be sent to that daemon process. This means that
mod_wsgi can associat sys.stderr for that daemon process with the
error log for that VirtualHost rather than it going to the global
Apache error log.
Graham
On Dec 20, 2:30 pm, Jeff Lindsay [EMAIL PROTECTED] wrote:
That doesn't seem to be the case. We're using this inside our VirtualHost:
ErrorLog /path/to/error_log
CustomLog /path/to/access_log combined
We're looking at the error_log file for this vhost and in embedded
mode we *do* see Pylons errors when raised but in daemon mode we do
not, which seems the opposite of what you say... except that we don't
get the errors in the main apache log either when in daemon mode.
This is Gentoo btw.
-jeff
On Dec 19, 2007 6:28 PM, Graham Dumpleton [EMAIL PROTECTED] wrote:
Which Apache error log file are you looking in? Do you have
VirtualHost specific CusomLog defined?
When run in mod_wsgi daemon mode, the sys.stderr output will be
redirected to a VirtualHost specific error log file if
WSGIDaemonProcess was defined in the context of the VirtualHost.
When in mod_wsgi embedded mode, the sys.stderr output will always go
to the main Apache error log file even if a VirtualHost specific error
log file has been defined.
Graham
On Dec 20, 10:30 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey Graham,
Actually, I thought I was having the same issue since I was getting no
logging at all from Pylons when using mod_wsgi. However, after trying
this and it not working, it looks like it has to do with using
mod_wsgi in daemon mode. (No, not on FreeBSD this time). I can seem to
log from the wsgi script, but once in Pylons it just doesn't spit
anything out unless running in embedded mode.
I'm simply using:
WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess localdev-site user=me group=me
WSGIProcessGroup localdev-site
WSGIScriptAlias / /path/to/script.wsgi
And I get nothing.
WSGIApplicationGroup %{GLOBAL}
#WSGIDaemonProcess
Re: mod_wsgi and pylons, Logging
Which Apache error log file are you looking in? Do you have
VirtualHost specific CusomLog defined?
When run in mod_wsgi daemon mode, the sys.stderr output will be
redirected to a VirtualHost specific error log file if
WSGIDaemonProcess was defined in the context of the VirtualHost.
When in mod_wsgi embedded mode, the sys.stderr output will always go
to the main Apache error log file even if a VirtualHost specific error
log file has been defined.
Graham
On Dec 20, 10:30 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey Graham,
Actually, I thought I was having the same issue since I was getting no
logging at all from Pylons when using mod_wsgi. However, after trying
this and it not working, it looks like it has to do with using
mod_wsgi in daemon mode. (No, not on FreeBSD this time). I can seem to
log from the wsgi script, but once in Pylons it just doesn't spit
anything out unless running in embedded mode.
I'm simply using:
WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess localdev-site user=me group=me
WSGIProcessGroup localdev-site
WSGIScriptAlias / /path/to/script.wsgi
And I get nothing.
WSGIApplicationGroup %{GLOBAL}
#WSGIDaemonProcess localdev-site user=me group=me
#WSGIProcessGroup localdev-site
WSGIScriptAlias / /path/to/script.wsgi
Will get me exception traces (the main reason I'm doing this) and
general logging, without any special setup, just using the default
pylons logging config and without the hack mentioned in this thread.
On a dual proc, dual core amd64 setup btw
-jeff
On Nov 17, 8:44 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
On Nov 17, 3:33 pm, PyDevler [EMAIL PROTECTED] wrote:
When I previously mentioned invistigating. I managed to get it to log
by manually adding a handler from within my controller-xyz.py. However
it is refusing to load my config. It is for some reason refusing to
use the Formatter line, that I adjust from within controller-xyz.py.
However, it changes the log-level which I also set in the same command
I pass the formatter string. I am unable to explain what pylons is
doing under mod-wsgi.
Sorry for taking so long to get back to this, got diverted on more
important things.
In the documentation for Pylons logging it says:
paster, when loading an application via the paster serve, shell or
setup-app commands, calls the logging.fileConfig function on that
specified ini file if it contains a 'loggers' entry.
logging.fileConfig reads the logging configuration from a ConfigParser
file.
This would suggest using 'paster' it does special stuff which wouldn't
be getting done if using mod_python, mod_wsgi or any other hosting
solution besides 'paster'.
The documentation is a bit deceiving here as took that to mean
'fileConfig' with 'logging' module, but on Python 2.3 at least, no
such function exists. Turns out what you need in WSGI script file is:
import os, sys
__here__ = os.path.dirname(__file__)
__parent__ = os.path.dirname(__here__)
sys.path.append(__parent__)
from paste.script.util.logging_config import fileConfig
fileConfig('%s/development.ini' % __parent__)
from paste.deploy import loadapp
application = loadapp('config:%s/development.ini' % __parent__)
Ie., fileConfig comes from 'paste.script_util.logging_config'.
If that function is called with Pylons ini file then logging if then
output.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: mod_wsgi and pylons, Logging
I am only referring to anything output directly via sys.stderr.
Any messages output via wsgi.errors passed in the WSGI environment,
which is how most WSGI application would tend to log, would go to the
log file associated with the context the request is handled in. If you
have a CustomLog in a VirtualHost container, then that is where those
messages would go. Any error messages generated by mod_wsgi, including
error tracebacks, which correspond to a specific request will
similarly be output to the error log file associated with the
VirtualHost if CustomLog is used.
The case which differs is when using sys.stderr directly, or where
using the logging module since it defaults to using sys.stderr also.
Because sys.stderr is global to the interpreter it isn't associated
with a specific request and so cannot normally be associated with the
custom log of the virtual host. This is the case because technically
it is possible for requests against different virtual hosts to be
directed to the same interpreter instance.
Daemon mode, where WSGIDaemonProcess is used inside of a VirtualHost,
is a special case because in that scenario, that the directive appears
inside of the VirtualHost means that only requests bound for that
virtual host could be sent to that daemon process. This means that
mod_wsgi can associat sys.stderr for that daemon process with the
error log for that VirtualHost rather than it going to the global
Apache error log.
Graham
On Dec 20, 2:30 pm, Jeff Lindsay [EMAIL PROTECTED] wrote:
That doesn't seem to be the case. We're using this inside our VirtualHost:
ErrorLog /path/to/error_log
CustomLog /path/to/access_log combined
We're looking at the error_log file for this vhost and in embedded
mode we *do* see Pylons errors when raised but in daemon mode we do
not, which seems the opposite of what you say... except that we don't
get the errors in the main apache log either when in daemon mode.
This is Gentoo btw.
-jeff
On Dec 19, 2007 6:28 PM, Graham Dumpleton [EMAIL PROTECTED] wrote:
Which Apache error log file are you looking in? Do you have
VirtualHost specific CusomLog defined?
When run in mod_wsgi daemon mode, the sys.stderr output will be
redirected to a VirtualHost specific error log file if
WSGIDaemonProcess was defined in the context of the VirtualHost.
When in mod_wsgi embedded mode, the sys.stderr output will always go
to the main Apache error log file even if a VirtualHost specific error
log file has been defined.
Graham
On Dec 20, 10:30 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey Graham,
Actually, I thought I was having the same issue since I was getting no
logging at all from Pylons when using mod_wsgi. However, after trying
this and it not working, it looks like it has to do with using
mod_wsgi in daemon mode. (No, not on FreeBSD this time). I can seem to
log from the wsgi script, but once in Pylons it just doesn't spit
anything out unless running in embedded mode.
I'm simply using:
WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess localdev-site user=me group=me
WSGIProcessGroup localdev-site
WSGIScriptAlias / /path/to/script.wsgi
And I get nothing.
WSGIApplicationGroup %{GLOBAL}
#WSGIDaemonProcess localdev-site user=me group=me
#WSGIProcessGroup localdev-site
WSGIScriptAlias / /path/to/script.wsgi
Will get me exception traces (the main reason I'm doing this) and
general logging, without any special setup, just using the default
pylons logging config and without the hack mentioned in this thread.
On a dual proc, dual core amd64 setup btw
-jeff
On Nov 17, 8:44 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
On Nov 17, 3:33 pm, PyDevler [EMAIL PROTECTED] wrote:
When I previously mentioned invistigating. I managed to get it to log
by manually adding a handler from within my controller-xyz.py. However
it is refusing to load my config. It is for some reason refusing to
use the Formatter line, that I adjust from within controller-xyz.py.
However, it changes the log-level which I also set in the same command
I pass the formatter string. I am unable to explain what pylons is
doing under mod-wsgi.
Sorry for taking so long to get back to this, got diverted on more
important things.
In the documentation for Pylons logging it says:
paster, when loading an application via the paster serve, shell or
setup-app commands, calls the logging.fileConfig function on that
specified ini file if it contains a 'loggers' entry.
logging.fileConfig reads the logging configuration from a ConfigParser
file.
This would suggest using 'paster' it does special stuff which wouldn't
be getting done if using mod_python, mod_wsgi or any other hosting
solution besides 'paster'.
The documentation is a bit deceiving here as took that to mean
