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? Is any of this stuff using a custom Python C extension 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. > 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. Graham
-- 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.
