Cache issue (reloaded ;-))
Emmanuel Blot
On one project, the wiki page index sometimes shows up a newly created
page, sometimes just ignores it.
The funny thing is that while the page did not show up in the page
index, I've still been able to access it, typing its exact URL in the
browser URL field. A colleague of mine just reported me that "one time
out of 10" a link from the WikiStart page pointing to this page
appears as a valid link, "9 time out of 10" it appears as a broken
link. It looks like some of the processes/threads know about the new
page, some do not.
I don't think if it's related or not, the page name does not follow
CamelCase name, and ends up with a '+' character.
Cheers,
Manu
Emmanuel Blot
> I think I hit another issue with the cache subsystem (Trac 0.12dev-r8162):
I've upgraded to Trac 0.12dev-r8176 (although the diff does not show a
relationship w/ the cache), then I've reloaded the Apache2 server, and
the problem disappeared (as I guess the cache has been reinitialized)
Remy Blank
> On one project, the wiki page index sometimes shows up a newly created
> page, sometimes just ignores it.
I assume the page is created by normal means, i.e. edition in the wiki
section?
> The funny thing is that while the page did not show up in the page
> index, I've still been able to access it, typing its exact URL in the
> browser URL field.
That's expected. We cache the list of available pages, which is not used
for checking if a page to be rendered exists or not.
> A colleague of mine just reported me that "one time
> out of 10" a link from the WikiStart page pointing to this page
> appears as a valid link, "9 time out of 10" it appears as a broken
> link. It looks like some of the processes/threads know about the new
> page, some do not.
That seems to indicate that the invalidation mechanism through the DB
did not work on that specific update, and only the process that was used
to create the new page got invalidated.
> I don't think if it's related or not, the page name does not follow
> CamelCase name, and ends up with a '+' character.
The page name should not matter, it's only contained in the cached
*data*, not the key.
Do you see any tracebacks in you log, possibly related to the creation
of the new page? It's kind of hard to debug, as the issue is transient
and resolves itself when you restart the web server. I'll add some
logging statements to the cache logic, hopefully this will show what's
happening in future occurrences.
Would you mind opening a new ticket for this issue? Please indicate the
DB backend you use, maybe the issue is DB-specific.
-- Remy
PS: Do you run multiple environments on your installation? I have the
uneasy feeling that my usage of thread-local storage might be
problematic in that case... A kind of cross-environment pollution, if
you will. To be investigated...
Emmanuel Blot
> section?
> Do you see any tracebacks in you log, possibly related to the creation
> of the new page?
Unfortunately, the log was set on "warning" level, so no error nor
warning (I double-checked before my irst post). I could had have
change the level, but this implies reloading Apache2, and "fix" the
transcient issue.
> Would you mind opening a new ticket for this issue?
Sure not, I'll do it
> Please indicate the DB backend you use, maybe the issue is DB-specific.
SQLite for now, I'll post the details within the ticket description.
Cheers,
Manu
Emmanuel Blot
http://trac.edgewall.org/ticket/8270
The "good" news is that I've been able to reproduce the error on the
very first test session.
Cheers,
Manu
Remy Blank
Thanks! I'll have a look tomorrow.
-- Remy
Christian Boos
Sorry, I was too intrigued to wait for tomorrow and *had* to have a look
at it ;-)
-- Christian
Emmanuel Blot
> at it ;-)
Thanks to both of you. ;-)
I'll upgrade our servers tomorrow.
Cheers,
Manu