On Jan 8, 3:38 am, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > 2009/1/6 rupert.thurner <rupert.thur...@gmail.com>: > > > while migrating our trac-0.11.2.1 installation from mod_python to > > mod_wsgi we got: > > [Mon Jan 05 19:28:34 2009] [info] [client x.x.x.x] (9)Bad file number: > > core_output_filter: writing data to the network > > > on the url:http://server.net/projects/testa/chrome/common/css/wiki.css, > > which then ends with an empty css file on the browser. > > > strange is that i cannot figure out a rule: > > *http://server.net/projects/testa/chrome/common/css/wiki.css- nok > > *https://server.net/projects/testa/chrome/common/css/wiki.css- ok > > *http://server.net/projects/testa/chrome/common/css/trac.css- ok > > *https://server.net/projects/testa/chrome/common/css/trac.css- ok > > > i also tried to grep for "wiki" in the apache config directory. but > > there is nothing, except the "watch /wiki/* " in the trac.ini file(s) > > for the announcer plugin. i also checked the permissions on the > > wiki.css inside the extracted python egg, installed via easy_install. > > > what could this be? all the urls worked with the mod_python > > configuration. > > I have been thinking about this for a while and no real answer. If it > only happens on that particular file and only for http request then it > is most strange. > > When using Trac such that it serves up static files it will use the > wsgi.file_wrapper extension. This extension results in Trac returning > an open Python file object onto the file wrapped in object instance > returned by wsgi.file_wrapper out of WSGI environment. From that file > object mod_wsgi does some checks and extracts a file descriptor. This > file descriptor is then wrapped in an Apache file bucket and it is > passed down the output filter chain and the output filter chain > flushed. As it is flushed, it should wait until all data is sent and > only then continue. This act of flushing should ensure that the Apache > file bucket is destroyed and any reference to the file descriptor it > has eliminated. After all done the wsgi.file_wrapper is destroyed and > that should then cause file object to be closed. As such, there should > not be any reason for Apache to have accessed the file descriptor > after it was closed. > > What the error message you are seeing is suggesting is that Apache is > accessing the file descriptor after the Python file object it is > associated with is destroyed. > > If this happened on every use of wsgi.file_wrapper I could understand > there being a bug in mod_wsgi logic, but if it only happens for one > file then it makes no sense. > > What we can do is confirm whether it is indeed related to wsgi.file_wrapper. > > To do this, use: > > _application = trac.web.main.dispatch_request > > def application(environ, start_response): > del environ['wsgi.file_wrapper'] > return _application(environ, start_response) > > By deleting the wsgi.file_wrapper from WSGI environment, Trac will > fall back to using its own wrapper object which sends data back in > blocks. If you don't see the error about bad file descriptor, then has > to somehow be related to wsgi.file_wrapper.
did it and it works now. i switched it into default mode in case an error turns out later. does the wsgi file wrapper make it somehow faster? > BTW, is the actual file content returned okay, and it is just a pain > that error message still returns, or is the file truncated when > returned. no, the css is empty. rupert. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to modwsgi@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 -~----------~----~----~----~------~----~------~--~---
