On Jan 11, 5:56 pm, Graham Dumpleton <[email protected]> wrote: > 2010/1/11 inaf <[email protected]>: > > > > > > > As I mentioned in one of the previous post, this script accesses a > > singleton object (well not quite a singleton object but close) where > > it reads from a class' variables (not sure if synchronization is > > required but I even tried that with lock.. still no luck). The problem > > is that this script is SSI'ed on a page 3 times with different > > parameters so it does not entirely break the page but these 3 places > > where it displays content, I think we are getting SSI error messages > > however I have not experienced it myself (I took out the "unable to > > include .." SSI errors from the log lines I pasted earlier not to > > confuse you as I don't think it has anything to do with it). We are > > putting a script in place to hit the page every so often and scrape > > the content hoping that in one of those runs, we will get this error > > and able to see what a user would see. The reason for doing this is > > that I was able to reproduce the error with another WSGI script that > > refreshes these class variables every once in a while via a job. I > > continously hit this URL in my browser and got the error in the logs > > but response was not always 500. It was able to get the result back > > successfully in some cases. So I want to see if the users really see a > > problem or somehow Apache tries to SSI the script again and is able to > > do so. > > Are you saying you are using Apache server side includes in static > files to virtual include a URL which corresponds to the WSGI script > file containing this code? Or when you say SSI are you meaning it in > the context of some specific Python web templating system? >
Yes, a bit more complicated than that actually.. request goes through this path: Lighttpd -> Apache --via mod_jk--> Tomcat and comes back the same way.. the content produced at Tomcat gets intercepted by Apache via location directives to execute virtual include lines that include a relative path which corresponds to the WSGI script. At that point mod_wsgi takes over and executes my WSGI script and the response gets injected before being returned to Lighttpd (nothing is done by Lighttpd) and finally to the user. > Is any of this stuff using a custom Python C extension module? None, as far as I know. I only have the python-memcached module (http://www.tummy.com/Community/software/python-memcached/), which I think is pure Python, in this environment as I don't need anything else. I do however use cPickle but not sure if that would cause an error like this. I did read the explanation you have on that issue but I am not using cPickle in the WSGI script itself. It is used in a Python file (methods and classes I coded) that I include as a module at the top of my WSGI script. So not sure it the same restrictions apply. I only get some values from memcached and unpickle (after uncompressing -- zlib module). > > > The other approach I have in mind is to see what is going through the > > unix socket between mod_wsgi daemon and apache. I am not quite sure if > > it is possible but still investigating. > > Only really practical by modifying mod_wsgi source code and having it > dump out to log files. I can give instructions on what code to add > later if it comes to that. We might need to try that but I think there are a few things I want to try before that. > > > Nonetheless, it is quite a strange problem and having these errors in > > the logs is not good since this means we are not defect free. I really > > do not want to throw away what I have implemented as it takes > > advantage of unique strengths of Python and is unbelievable fast and > > not resource intensive at all thanks to mod_wsgi. I really appreciate > > your work and have so much respect for what you are doing. Thanks once > > again for making my idea a reality.. well almost there :) > > Can you possibly use mod_wsgi 3.1 instead of mod_wsgi 2.6. > > The code where those error messages is generated has been changed > around in mod_wsgi 3.0. I don't believe it was addressing any specific > problems, but would be good to see if issue resolves itself doing > that. > Already did that a few days back on one node and the errors I pasted (if I am not mistaken) were from that node.. so the problem is still there even with the upgrade.. Tried disabling siteminder module and could not reproduce this error in pre-prod.. so it might be the memory allocation problem you described earlier.. logged a case with siteminder to see if they can provide any insight.. -Cem > Graham- Hide quoted text - > > - Show quoted text -
-- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
