Christian Boos <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> David Abrahams
>> <[EMAIL PROTECTED]> writes:
>>
>>> I'm getting persistent tracebacks from all my trac (0.9.5)
>>> installations (on an old BSD) that use authentication. Usually the
>>> tracebacks go away if I just refresh the page, but I'm really
>>> concerned that it's not working very professionally. For example, in
>>> FireFox 1.5, I'm logged in, and I visit the roadmap page. What I see
>>> in the browser is a mixture of HTML and tracebacks (below).
>>>
>>> When I choose "View > Page Source" I get what looks like perfectly
>>> clean HTML, but maybe that's because the page gets reloaded at that
>>> point.
>>>
>>> Does anyone know what's going on here?
>>
>> FWIW, my server is slow. Is there a chance there's some timing issue
>> that could be causing this problem?
>
> You certainly didn't configure Trac and Apache the right way,
> so that your static resources are served directly by Apache.
>
> Check:
> http://projects.edgewall.com/trac/wiki/TracCgi#MappingStaticResources
> http://projects.edgewall.com/trac/wiki/TracModPython#Using/tracrootURL
>
> If you don't do that, Trac will serve the static content directly,
> by using its "Chrome" component.
I certainly did try to follow those instructions.
I have
...
Alias /trac-htdocs /usr/local/boost/share/trac/htdocs
<Directory "/usr/local/boost/share/trac/htdocs">
Options Indexes Multiviews
Order allow,deny
Allow from all
</Directory>
...
in httpd.conf and
...
[trac]
default_charset = iso-8859-15
ignore_auth_case = false
permission_store = DefaultPermissionStore
check_auth_ip = true
database = sqlite:db/trac.db
templates_dir = /usr/local/boost/share/trac/templates
default_handler = WikiModule
metanav = login,logout,settings,help,about
htdocs_location = /trac-htdocs
...
in trac.ini
And I'm using fastcgi, not mod_python. Is that second link relevant?
If so, shouldn't teh TracCGI page be updated?
> The behavior of this component is quite catastrophic in case of an
> authentified access, especially with Trac 0.9.x:
> the request for the main page will trigger a *save* to the db,
> and the secondary requests (for the static resources) will then
> trigger a *read* from the db.
> If your server is not fast enough, this will most likely result
> in several failed requests, due to the database being locked.
Hm. That sounds like a likely culprit. But then, what's wrong with
my config? As I said, I tried to get the static resources to be
served directly by Apache.
> In 0.10, that situation has been much improved:
> * the Chrome component doesn't need access to the database anymore,
> in order to serve the static content;
> * the session handling code has also been improved recently
> (though I haven't checked yet if there's still a systematic
> attempt to write to the db for every authentified request)
>
> So either switch to 0.10 or configure Apache so that it serves
> directly the static content. Either way you'll most certainly
> see a dramatic speed improvement, even on your slow server :)
Thanks, I must be missing something trivial, then.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
