FYI.
http://wsapi.luaforge.net/
For example:
function hello(wsapi_env)
local headers = { ["Content-type"] = "text/html" }
local function hello_text()
coroutine.yield("")
coroutine.yield("Hello Wsapi!")
coroutine.yield("PATH_INFO: " .. wsapi_env.PATH_INFO .. "")
coroutine.
2008/8/20 gert <[EMAIL PROTECTED]>:
>
> On Aug 19, 1:30 am, "Graham Dumpleton" <[EMAIL PROTECTED]>
> wrote:
>> FYI.
>>
>> http://wsapi.luaforge.net/
>>
>> For example:
>>
>> function hello(wsapi_env)
>> local
2008/8/22 Olive <[EMAIL PROTECTED]>:
>
> Hi,
>
> here are my results:
>
> mod_wsgi 2.1:
>
> un-cPickle: 4.44s
> dict op: 0.07s
>
>
> mod_python 3.2.8:
>
> un-cPickle: 2.13s
> dict op: 0.07s
>
>
> Command line:
>
> un-cPickle: 1.26s
> dict op: 0.08s
>
>
> Linux RHEL, Python 2.4.3, Apache 2.2.
Thanks for the detailed information.
I was offline yesterday, so just catching up on emails etc. With this
I should be able to duplicate it with just wsgi.file_wrapper and not
even require Trac. I'll get on to this one today.
Thanks again.
Graham
2008/8/22 illuminarti <[EMAIL PROTECTED]>:
>
>
ver the lazy dog!1234
> The quick brown fox jumped over the lazy dog!12345The quick brown fox jumped
> over the lazy dog!1234
> The quick brown fox jumped over the lazy dog!12345The quick brown fox jumped
> over the lazy dog!1234
> The quick brown fox jumped over the lazy dog!12345
se of sendfile techniques isn't used and
so any problem would lie in mod_wsgi somewhere. I'll need to disable
the sendfile code manually and then see what happens.
Graham
2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>:
> 2008/8/22 Simon J. Oliver <[EMAIL PROTECTED]>:
>>
xed in mod_wsgi 3.0
development version as don't have the problem there. :-)
Just need to work out what changed.
Graham
2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>:
> Ignore that, my test code below is somehow flawed.
>
> Even if I write a file containing 8192 null characte
g some progress with it :-)
>
> As it happens. I'm using the macports python 2.5 on that that machine,
> but that probably doesn't make any difference, given what you're
> seeing. I am still using the 1.3.41 apache that came with Tiger, though.
>
>
&
return environ['wsgi.file_wrapper'](data, 4096)
Graham
2008/8/22 Graham Dumpleton <[EMAIL PROTECTED]>:
> Following code in mod_wsgi is wrong:
>
>if (*PyString_AsString(result) == '\0') {
>PyErr_SetObject(PyExc_StopIteration, Py_None);
>Py_D
imple answers for those now, plus haven't
had a huge amount of time lately to work on it.
Graham
> Simon
>
>
>
>
>
> On Aug 21, 2008, at 10:12 PM, Graham Dumpleton wrote:
>
>>
>> On Apache 2.X on UNIX, you would also have had problems if file like
>
2008/8/22 Olive <[EMAIL PROTECTED]>:
>
>
> After further testing I've noticed this:
>
> Just after restarting Apache:
> mod_python: 2.52s
> mod_wsgi: 2.08s
>
> subsequent requests give more or less the same results.
>
> After 9 requests or so:
> mod_python: 5.28s
> mod_wsgi: 4.5s
>
> ... and so on
Details can be found at:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0105
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202
Important changes are file descriptor leaks on a graceful restart in
both versions and for version 2.2 possible truncation of data when
using wsgi.fi
2008/8/22 Olive <[EMAIL PROTECTED]>:
>
> OK,
>
> I have added this to httpd.conf:
> WSGIPythonPath /data/search/modwsgi
>
> and this to my app:
> from loaddb import ipcindex
>
> The first 8 requests are slow (loadding the pickled object I guess).
> Subsequent ones are blazing fast !
>
> What's wro
2008/8/22 Nimrod A. Abing <[EMAIL PROTECTED]>:
>
> On Fri, Aug 22, 2008 at 2:43 PM, Graham Dumpleton
> <[EMAIL PROTECTED]> wrote:
>>
>> Details can be found at:
>>
>> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0105
>> http://
> auth.
>>>
>>> I never found a solution for http auth, I used IP based authentication
>>> rules instead.
>>>
>>> --
>>> Milan
>>>
>>> On Fri, Aug 22, 2008 at 12:45 PM, mrts <[EMAIL PROTECTED]> wrote:
>>> >
2008/8/22 Nimrod A. Abing <[EMAIL PROTECTED]>:
Important changes are file descriptor leaks on a graceful restart in
both versions and for version 2.2 possible truncation of data when
using wsgi.file_wrapper. An upgrade would be recommended especially
due to the latter if using
2008/8/22 Nimrod A. Abing <[EMAIL PROTECTED]>:
>
> On Fri, Aug 22, 2008 at 9:01 PM, Nimrod A. Abing <[EMAIL PROTECTED]> wrote:
>>> Thus, long running file uploads perhaps better handled in embedded
>>> mode, or delegate the URLs for file upload to special daemon process
>>> that doesn't recycle pr
Are you using mod_cgi or mod_cgid?
Graham
2008/8/23 Douglas Thrift <[EMAIL PROTECTED]>:
>
> Hello,
>
> This is really strange, but after upgrading from 2.1 I was looking at my
> website and noticed that all of my CGI scripts were returning 500 errors and
> in the log it was just saying "Prematur
2008/8/23 Nimrod A. Abing <[EMAIL PROTECTED]>:
>
> On Sat, Aug 23, 2008 at 1:33 PM, Graham Dumpleton
> <[EMAIL PROTECTED]> wrote:
>>
>> 2008/8/22 Nimrod A. Abing <[EMAIL PROTECTED]>:
>>>>>> Important changes are file descriptor leaks on a
las William Thrift
> <[EMAIL PROTECTED]>
> <http://www.douglasthrift.net>
>
> ----- Original Message -
> From: "Graham Dumpleton" <[EMAIL PROTECTED]>
> To:
> Sent: Saturday, August 23, 2008 3:57 AM
> Subject: [modwsgi] Re: mod_wsgi 2.
This quick turn around version is to fix problem with 2.2 which caused
CGI scripts to fail. See:
http://groups.google.com/group/modwsgi/browse_frm/thread/79a86f8faffe7dcf
The problem may also have possibly affected other Apache modules as well.
If you obtained version 2.2 already, it is highl
Released version 2.3 to fix this.
2008/8/23 Graham Dumpleton <[EMAIL PROTECTED]>:
> Okay, confirmed on MacOS X 10.5.
>
> It only happens when WSGIDaemonProcess directive used with mod_wsgi.
>
> Patch is:
than one daemon process in the group
I guess a mod_wsgi 2.3 will be in order, but need to also fix
setprocttitle() call first as well. :-)
Graham
2008/8/23 Graham Dumpleton <[EMAIL PROTECTED]>:
> Right now I cant see how mod_wsgi 2.2 changes could be affecting CGI
> scripts, so plea
2008/8/24 Nimrod A. Abing <[EMAIL PROTECTED]>:
>>> Our config does not have maximum-requests specified. You do bring up a
>>> very good way of dealing with scaling issues that we are anticipating.
>>
>> I am not sure what part of what I said is relevant to 'scaling'. In
>> general when scaling is
2008/8/24 William Dode <[EMAIL PROTECTED]>:
>
> Hi,
>
> Is it a good idea to start a maintenance thread with WSGIImportScript.
There is nothing wrong with doing that. You may want to have a look at:
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
In particular section 'Restarting Da
t; On Sun, Aug 24, 2008 at 12:47 PM, Graham Dumpleton
> <[EMAIL PROTECTED]> wrote:
>>> The plan is to use the system found in Chapter 20 of the Django book:
>>>
>>> http://www.djangobook.com/en/1.0/chapter20/
>>>
>>> See figure 20-4
>>>
Damn, forgot to update the internal version mod_wsgi version numbers
again. At least I remember the version string this time. :-)
Graham
2008/8/23 Graham Dumpleton <[EMAIL PROTECTED]>:
> This quick turn around version is to fix problem with 2.2 which caused
> CGI scripts to fail. Se
e /home/bob/sites/project/svn/repos
>
> DAV svn
> SVNPath /home/bob/sites/project/svn/repos
> AuthType Basic
> AuthName "New Software Repository"
> AuthBasicProvider wsgi
> WSGIAuthUserScript /home/bob/public_html/auth.wsgi
> Require valid-user
>
>
>
> Any
2008/8/25 mrts <[EMAIL PROTECTED]>:
>
> Graham, let me first thank you for mod_wsgi. It is just excellent.
>
> I really would like to arrange some donations to thank you for
> mod_wsgi development (unfortunately nothing grand, but perhaps others
> will follow the lead... ping, Google?). However, i
2008/8/25 mrts <[EMAIL PROTECTED]>:
>
> First, let me say that
>
> AuthBasicProvider wsgi
> WSGIAuthUserScript /usr/local/wsgi/scripts/auth.wsgi
>
> works well for me with Django (there were some issues reported in
> another thread).
>
> But having access only to a limited environment, user and pa
2008/8/26 Garito <[EMAIL PROTECTED]>:
>
> Anyone has a good example or tutorial about how to integrate Authkit
> with mod_wsgi?
As mod_wsgi is just a WSGI implementation, anything which explains how
to use AuthKit for WSGI should give you want you want.
I haven't read it, but perhaps have a look
FYI. I manage to get drawn into posting a big long rant about mod_wsgi
in followup to some comments about adding WSGI support to Cherokee
HTTPd. The rant may be partly of interest to some:
http://groups.google.com/group/cherokee-http/browse_frm/thread/d5506804396f9a6c?hl=en
Now if I can only
Since I am pointing out posts elsewhere where I have been ranting.
Here is another one in followup to someones blog post about Django and
mod_wsgi. In this case was mainly responding to someone elses comment
rather than actual blog.
Again, the comments may be of interest.
http://www.technobabble
Adal,are you still around?
I notice that Windows binaries for mod_wsgi haven't been updated in a
while. The latest 2.3 version really needs a Windows version as it
fixes issues present on Windows.
Graham
--~--~-~--~~~---~--~~
You received this message because you
2008/8/26 Garito <[EMAIL PROTECTED]>:
>
> Hi!
> My last question about Authkit was in order to operate with the
> filesystem with a concrete user and in the last post to the list you
> send a Django and mod_wsgi article that uses WSGIDaemonProcess
> directive to force mod_wsgi to run with a partic
2008/8/26 Florent Aide <[EMAIL PROTECTED]>:
>
> On 8/26/08, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
>>
>> Since I am pointing out posts elsewhere where I have been ranting.
>> Here is another one in followup to someones blog post about Django and
&
Bernd, I noted:
http://groups.google.com/group/linux.debian.devel.release/browse_frm/thread/ceb8a5eee715caa0/a1f8202f1faf8026?lnk=st&q=wsgi#a1f8202f1faf8026
but don't quite understand what all of:
http://packages.qa.debian.org/m/mod-wsgi.html
actually means.
Can you explain how different
in the main
Apache configuration. It is this way as Apache has to be able to see
WSGIDaemonProcess when it starts up to know what processes to create.
WSGIProcessGroup is only allowed in main Apache configuration so that
it isn't possible in a shared hosting environment for some mortal user
to f
As part of the process of improving wiki documentation for mod_wsgi,
which everyone is encouraging me to do, I have extracted and trimmed
slightly the build and installation notes from the README in the
source code and stuck them in a wiki document.
If interested parties could read it and provide
t using WSGIApplicationGroup. Adding it did not change the outcome,
> though, as I received the same errors and 200 Continue response.
>
> In addition to Django, I have MySQL-python, numpy, psycopg2, PyXML, and
> genshi installed on the server, although I don't use any of
I thought they didn't interfere, having different names and
> WSGIProcessGroup.
> What's the right way to make two daemon cohexist in the same host? Should I
> put WSGIProcessGroup inside a Location for the given alias?
>
> giovanni
>
> 2013/7/23 Graham Dumpleton
Do you have:
WSGIApplicationGroup %{GLOBAL}
in your Apache/mod_wsgi configuration?
See:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>From memory lxml is one these third party extension modules which is affected
>by this.
Graham
On 29/07/2013, at 3
What is the error in the Apache error logs?
At a guess it is because you aren't supplying an absolute path to the location
of the newrelic.ini file.
The working directory of Apache isn't going to be the directory where your code
is.
So use something like:
import os
import newrelic.agent
newre
Is the newrelic module installed into a Python virtual environment or into a
real Python installation?
That it is not found suggests a few possibilities.
1. The mod_wsgi is compiled against a different Python version.
2. You have a distinct Python 2.7 installation (system wide one) which is
dif
Can you please provide the outputs of the tests I asked you to do so I can
check for myself and look for anything strange.
Thus the output from ldd (ensuring LD_LIBRARY_PATH is not set), sys.prefix and
sys.version etc.
Also provide the WSGI directives from Apache configuration file as asked.
P
Please ensure you reply to the same message properly. You keep creating new
messages which destroys the discussion thread.
On 30/07/2013, at 5:24 PM, virgil.balibanu wrote:
> 1.
> [root@vps701 sbo]# locate mod_wsgi.so
> /usr/lib/httpd/modules/mod_wsgi.so
> [root@vps701 sbo]# ldd /usr/lib/httpd
Mostly it looks like a relative pathname is being used rather than absolute.
Thus is trying to right to / as that is what working directory usually is. So
permissions is an issue, but using an absolute path to a specific directory
would be the first thing to solve.
Graham
On 03/08/2013, at 9:5
, Frank He wrote:
> Seemed like this is configuration of cache directory, are there any setting
> that can change cache directory in django setting?
>
> On Friday, August 2, 2013 7:53:46 PM UTC-7, Graham Dumpleton wrote:
> Mostly it looks like a relative pathname is being used rathe
What operating system?
Where and when do you see this?
Please provide more context. Actual cut and paste of command run where you see
this if was when running command and all the output from it.
Or more of the log before and after if this is at there and at time of request
If a python exceptio
Don't compile yourself from source on Windows. Try and use instead binaries
from:
http://www.lfd.uci.edu/~gohlke/pythonlibs/
Make sure you use all 32 bit binaries or all 64 bit binaries for Python, Apache
and mod_wsgi. Do not mix 32 bit and 64 bit.
Python must be installed for all users and no
The error occurs when a WSGIDaemonProcess directive with the same name, e.g.:
'mumble-django' in:
WSGIDaemonProcess mumble-django threads=25
appears more than once.
If you are confident that only appears in one file and only once, then likely
your Apache config is somehow screwed up such
Usually this is the result of the shared libraries required by PIL not being in
standard library directories. They are possibly being found when you use a
normal shell because you have LD_LIBRARY_PATH set.
So, what is LD_LIBRARY_PATH set to in your normal account?
What do you get when you run:
On 13/08/2013, at 8:24 AM, Patrick Joy wrote:
> _application = django.core.handlers.wsgi.WSGIHandler()
>
> import posixpath
>
> def application(environ, start_response):
> # Wrapper to set SCRIPT_NAME to actual mount point.
> environ['SCRIPT_NAME'] = posixpath.dirname(environ['SCRIPT_N
On 13/08/2013, at 8:24 AM, Patrick Joy wrote:
>
> My django.wsgi looks like this.
>
> ALLDIRS =
> ['/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.7/site-packages/']
> APP_NAME = 'MYAPP'
> import os, sys, site
>
> # virtualenv stuff --
> prev_sys_path = list(sy
-gnu/libz.so.1 (0x7f62d754d000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f62d732f000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f62d6f67000)
> /lib64/ld-linux-x86-64.so.2 (0x7f62d7bff000)
>
> On 13/08/13 22:07, Graha
e one
process in different sub interpreters.
Graham
On 13/08/2013, at 9:22 PM, Patrick Joy wrote:
>
> On 13/08/13 22:10, Graham Dumpleton wrote:
>> On 13/08/2013, at 8:24 AM, Patrick Joy wrote:
>>
>>> _application = django.core.handlers.wsgi.WSGIHandler()
>&g
o errors are recorded and I can use
> PIL features in my django app.
>
> The only time I get an error is if I add import PIL._imagaing to my wsgi
> script at the top (before the paths are set).
>
> Patrick
>
> On 13/08/13 23:21, Graham Dumpleton wrote:
>> If you edit
very old wsgi script has been performing fine.
>
> Patrick
>
> On 13/08/13 23:42, Graham Dumpleton wrote:
>> Since you appear to have issues with conflicting packages in system Python
>> and virtualenv, would definitely recommend using that python-home option to
>> WSGID
Can you indicate what you haveWSGISocketPrefix set to?
It is a bit odd to have them in a sub directory of /var/tmp as mod_wsgi will
not create directories and they would need to exist first. This implies your
would have had to create hat directory in /var/tmp yourself, and being in
/var/tmp, so
Run the Apache executable with the -M option to verify that mod_wsgi is
actually being loaded:
/usr/sbin/httpd -M
You should see in the output.
wsgi_module (shared)
Then ensure you have LogLevel set to 'info' and look for any mod_wsgi messages
in Apache error log.
Graham
On 22/08/2013, at
watch. It has a line like /usr/sbin/tmpwatch "$flags" 30d
/var/tmp or /usr/sbin/tmpwatch 720 /var/tmp. 720 hours = 30 days.
So looks like it is possible that some systems clear out stuff from /var/tmp on
a periodic basis.
Graham
> On Tuesday, August 20, 2013 10:00:38 PM UTC-4, Gr
d -M" or adding -M in my current command, i.e.,
> "httpd -M -f -k start"?
>
> On Wednesday, August 21, 2013 10:15:28 PM UTC-4, Graham Dumpleton wrote:
> Run the Apache executable with the -M option to verify that mod_wsgi is
> actually being loaded:
>
> /usr/sbi
_mod_path/mod_wsgi.so into server: libpython2.6.so.1.0: cannot open
> shared object file: No such file or directory
>
> where line 2 is " LoadModule wsgi_module modules/mod_wsgi.so"
>
> On Wednesday, August 21, 2013 10:52:45 PM UTC-4, Graham Dumpleton wrote:
> Run it
For you to get a 500 error would imply your requests weren't able to finish
within 2.5 seconds, which is how long they would be given before the process
was killed off anyway.
How long do your requests run for?
In mod_wsgi 4.0 there will be slightly more flexibility in this, because a
separate
Quoting the home page of the mod_wsgi site:
"""
An alternate mode of operation available with Apache 2.X on UNIX is 'daemon'
mode. This mode operates in similar ways to FASTCGI/SCGI solutions, whereby
distinct processes can be dedicated to run a WSGI application. Unlike
FASTCGI/SCGI solutions h
The main rules for getting mod_wsgi to work on Windows are.
1. You MUST use all 64 bit versions of mod_wsgi, Apache and Python, or all 32
bit versions. You cannot mix.
2. You MUST install Python for all users and not just the user Python was
installed from.
3. You MUST use the same Python major/
Can you send me what the various CPPFLAGS, CFLAGS, LDFLAGS and LDLIBS lines in
the generated Makefile say?
For now you will need to edit the generated Makefile and remove the offending
option before doing the build.
Graham
On 16/09/2013, at 11:33 PM, Gnarlodious wrote:
> At the end of the "m
To have it show completely different runtime version like that would normally
suggest that you are also loading mod_python on that server. See:
http://code.google.com/p/modwsgi/wiki/InstallationIssues#Python_Version_Mismatch
Also note you cannot use WSGIPythonHome to point mod_wsgi at a differen
You have a very poorly setup configuration. Your WSGI application can only
handle one request at a time. If one request takes a long time to run, it will
block out everything else and if it blocks for too long, it will timeout.
I would thus very much suggest not using processes=1 and threads=1 f
On 18/09/2013, at 10:47 AM, Graham Dumpleton wrote:
> You have a very poorly setup configuration. Your WSGI application can only
> handle one request at a time. If one request takes a long time to run, it
> will block out everything else and if it blocks for too long, it will timeou
tings for "processes=" and "threads="?
>
>
>
> On Tuesday, September 17, 2013 7:51:18 PM UTC-5, Graham Dumpleton wrote:
>
> On 18/09/2013, at 10:47 AM, Graham Dumpleton wrote:
>
>> You have a very poorly setup configuration. Your WSGI application c
It all depends on your specific application.
It is also depends on you having got the configuration correct for Apache and
mod_wsgi.
You would need to supply your mod_wsgi configuration so can comment on whether
it does what you think it should.
For some background on working out where bottlen
On 24/09/2013, at 9:57 PM, Sebastian Clemens wrote:
> Ok, some more about my system: running Debian 6 and Plesk 11, 2GB RAM (and
> 50% is already in use) and the important part of my config:
>
> WSGIProcessGroup ssl.sebastian-clemens.de
> WSGIApplicationGroup ssl.sebastian-clemens.de
> WSGIDae
I'll have a dig through Apache and see what I can work out, but have you ever
looked at New Relic? It provides this sort of information in an easily
digestible UI. It provides a free Lite tier which although it doesn't provide
all features of the product, still provides a lot of useful stuff.
C
Try setting:
WSGIApplicationGroup %{GLOBAL}
For reasons why, see:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions#Apache_Process_Crashes
If stil, no joy, have a look at the page linked there a
How is the file being accessed from the NFS file system being delivered back to
the client?
If the code is ultimately using wsgi.file_wrapper, try setting:
WSGIEnableSendfile Off
The EnableSendfile directive only applies to static files Apache itself serves.
Those delivered by mod_wsgi using w
Please read:
http://code.google.com/p/modwsgi/wiki/InstallationIssues#Mixing_32_Bit_And_64_Bit_Packages
You need to do a make distclean on your original Python source code and
rebuild/reinstall it. This time ensure you use the --enable-shared option to
the Python configure script.
Graham
On 2
As per instructions at:
https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/
The first argument to WSGIScriptAlias is a path and not a URL.
You should therefore be using:
WSGIScriptAlias /ktksurvey/ktkanketa
"D:/Research/09-BuildingARecommender/xampp/htdocs/ktksurvey/ktkanketa/
low
> Allow from all
>
>
>
>
> however it doesn't seem to do the trick.
> Am I missing something?
>
> (again on the runserver css was used normally)
>
> Thanks in advance!
>
> On Wednesday, October 2, 2013 10:19:47 PM UTC+2, Graham
More specifically, you are trying to do things as a CGI script, which has
nothing to do with mod_wsgi. For information on CGI and Python in Apache, see:
http://webpython.codepoint.net/cgi_tutorial
Graham
On 04/10/2013, at 4:47 AM, Jason Garber wrote:
> Steve, this email clearly demonstrates t
What are you actually setting the user and group to?
The issue is logged here:
http://code.google.com/p/modwsgi/issues/detail?id=288
Looking at the code properly, I am wondering whether there is an inverse logic
bug.
The code does:
if (!strcmp(option, "user")) {
if (!*valu
On 08/10/2013, at 3:43 AM, Rodrigo Campos wrote:
> On Fri, Oct 04, 2013 at 12:28:21PM -0700, Rob Newman wrote:
>> Hi mod_wsgi folks,
>>
>> I am an avid user of mod_wsgi, and have been asked for my opinion on how to
>> best host a web-based Python-powered app that has bad memory management.
>>
Why is it that when you reply it is never to the replies sent back to you?
Instead it comes back as a disconnected message stream against your own
original questions. This makes it impossible to follow the conversation as the
context has been lost. If this is simply how your mail reader works, t
Try adding to the Apache configuration:
WSGIApplicationGroup %{GLOBAL}
The bumpy module is from memory one which will not work in sub interpreters, so
you need to force it to run in the main global interpreter, which is what the
directive does.
I would also suggest you look into using daemon m
Both are valid configurations and can work, but achieve different results.
What you don't show is how you are mounting the WSGI applications. Are you
using WSGIScriptAlias or are you using AddHandler/SetHandler? Also what web
framework are you running?
Without that information and also a better
f you never have any monitoring it is
always harder to look back and guess why something occurred. It may be prudent
therefore to consider using some sort of monitoring so you have historical
information to debug what did actually happen.
Graham
> Am Freitag, 11. Oktober 2013 11:3
"[error] ImportError:
> numpy.core.multiarray failed to import"
>
> As a daemon service. I tried adding the following to my httpd.conf
>
> WSGIPythonHome /usr/local
> WSGIPythonPath /usr/local/lib/python2.7/site-packages/
> WSGIApplicationGroup %{GLOBAL}
> WSGIDaemonProces
;
> The "all over the place" was that there are several
> devel-copies of the same site and the wrong copy was being loaded. Known
> problem when WSGIProcessGroup is either wrong or missing if google is to be
> believed.
>
>
>
> On 12 October 2013 04:40, Grah
I would generally recommend delegating each to its own daemon process group.
This then allows you to do a number of things.
The first is that you can force each to run in the main interpreter context of
their respective processes. This avoids issues with third party extension
modules for Python
Turn off fancy quotes in your editor. Remove those fancy double quotes or
replace them with normal double quotes.
This is on WSGIScriptAlias as well as Directory directive.
Graham
On 21/10/2013, at 8:55 AM, Akshatha G Bhat wrote:
> I have just started to work on Apache-wsgi-django.
>
> I wan
The mod_wsgi module will be compiled for a specific Python version. You should
not put it at a different versioned Python installation or even Python modules
installed into the site-packages/dist-packages of a different versioned Python
installation as what is installed can be incompatible, espe
Schwalenberg
wrote:
> sys.version = '2.7.3 (default, Sep 26 2013, 20:13:52) \n[GCC 4.6.3]'
> sys.prefix = '/usr'
>
>
> On Wednesday, October 23, 2013 1:14:21 PM UTC-4, Graham Dumpleton wrote:
> The mod_wsgi module will be compiled for a specific Python version. Y
dist-packages/ubuntuone-control-panel',
> '/usr/lib/python2.7/dist-packages/ubuntuone-couch',
> '/usr/lib/python2.7/dist-packages/ubuntuone-installer',
> '/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol'
>
> Strangely the directory for t
m
> /home/python/myPackage directory. It could be a permissions issue. There is
> an easy_install.pth that contains a link to my home folder/python as well.
>
> On Wednesday, October 23, 2013 3:08:03 PM UTC-4, Graham Dumpleton wrote:
> Can you explain more when you say you installed
What is the actual error you are getting? Where is the error appearing? Is
there nothing else in the Apache error log after that point?
Graham
On 24/10/2013, at 1:15 PM, Quin Arnold wrote:
> I've seen several posts that talk about using flask with mod_wsgi; however i
> cannot seem to get it t
Upgrade mod_wsgi.
>From memory, the subversion crashes was addressed in mod_wsgi 3.4 by:
7. Response Content-Type header could be corrupted when being sent in
multithreaded configuration and embedded mode being used. Problem thus
affected Windows and worker MPM on UNIX.
Require valid-user
> WSGIAuthGroupScript /var/lib/wsgi/access.wsgi
> Require group authorized
>
>
>
> (This has been reconfirmed with mod_wsgi 3.4.) And we know that the
> intended configuration
> works as expected with mod_dav_svn from
Add:
WSGIRestrictEmbedded On
to avoid initialising the Python interpreter in every Apache child worker
process.
Especially since you are using embedded mode with what looks like Apache
default MPM settings, you are setting yourself up for some pain.
For more details watch:
http://lanyrd.
ham
> Anything else which I can specify/modify in the conf file to speed up boot
> time?
>
> On Tuesday, November 5, 2013 1:30:18 PM UTC+5:30, Graham Dumpleton wrote:
> Add:
>
> WSGIRestrictEmbedded On
>
> to avoid initialising the Python interpreter in every Apache c
Have they always used pyrex? I though they were pure Python.
Anyway, likely that they are now producing a package with a C extension that
will not work in Python sub interpreters.
Are you setting the WSGIApplicationGroup directive to anything in your Apache
configuration?
For background of pot
1 - 100 of 5315 matches
Mail list logo
