On Wednesday 15 October 2008 15:14:41 Lukasz Szybalski wrote: > On Wed, Oct 15, 2008 at 7:09 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > > Hi Graham, > > > >> > I'm running apache2,mod_wsgi2.0, python2.5. > >> > >> Why aren't you using latest mod_wsgi 2.3? > > > > Because I've set up the machine a few months ago and wasn't aware that > > there is a newer version. I now upgraded. > > > >> > THis is the startup message: > >> > > >> > http://paste.turbogears.org/paste/9664 > >> > >> Are you still using mod_python? If not, disable it out of Apache as it > >> can cause problems for mod_wsgi. > > > > I now disabled it. > > > >> Did you completely 'stop' and then 'start' Apache after making any > >> recent changes, or at least touch the WSGI script file so daemon > >> processes would be reloaded. > > > > Yes, complete restarts. > > > >> > The vhost-conf: > >> > > >> > http://paste.turbogears.org/paste/9666 > >> > >> Why don't you have a ServerName directive inside VirtualHost? If only > >> serving one site and using ServerName from main configuration context, > >> you probably don't need the VirtualHost container then. > > > > Because I just took what the ubuntu system was coming with, and don't > > know much about apache configuration. Do you think it might affect the > > problem? > > > >> > The boostrap-wsgi-script: > >> > > >> > http://paste.turbogears.org/paste/9667 > >> > > >> > If there is *anything* enlightening to say about this, I'm more than > >> > glad to hear it. > >> > > >> > I had the high hopes that such kind of behavior that I've seen PHP > >> > exhibit would be something from a better forgotten dark past... > >> > >> Can you make it clear whether the 404 is generated by Apache or by > >> TurboGears? > > > > After putting a logging-middleware in front of my application, it appears > > that the python/TG-code is responsible, not apache. See below for more > > remarks. > > > >> Post the lines from the Apache access log which show the 404 errors > >> for the request. Are the URLs there what you expect to see? > >> > >> For more in depth debugging of request and response at WSGI level, use > >> second recipe in: > >> > >> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Reque > >>st_ and_Response > >> > >> to capture the complete request and response. Look at them to see if > >> they are what you expect. > > > > Thanks, I did that. After doing the update, things changed *slightly*: > > the problem remains that loading a page itself works, yet *some* of it's > > referred resources (mostly javascript, sometimes images) produce a 404. > > > > However, the behavior that putting the url in question (e.g. > > http://localhost/collaborate/toscawidgets/resources/ableton.collaborate.f > >rontend/public/javascript/jquery/cluetip/jquery.cluetip.js ) into a tab, > > and pressing F5 frequently would show the intermittent 404, or sometimes > > the resource, seems to be gone. > > Try changing the settings in a wsgi to a deamon mode with 10 threads > and 3 processes(or what ever number you need it to be) and then test > your 404 again. This should fix your problem.
That didn't help. Setting the process to 1 *did* help, not to surprising. Any other suggestions. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
