Edgewall Software
Modify

Opened 15 years ago

Closed 15 years ago

#8242 closed defect (fixed)

Issue w/ the cache subsystem

Reported by: Emmanuel Blot Owned by: Remy Blank
Priority: normal Milestone: 0.12
Component: general Version: 0.12dev
Severity: major Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

When a new component is added, through the webadmin interface, it may or may not appear in the Ticket page.

I've bumped into two different cases:

  1. The new component is added after a "New ticket" page is filled in, and before the new ticket is submitted. A "Preview" action used to reload the new ticket page and update the selection list on-the-fly, allowing to set the newly created component before creating the actual ticket.
    • this feature worked, but when the ticket got submitted, the server rejected the new component as "Invalid": it looks like several instances of the Trac server do not get synchronized as they should fo
  2. Far worse, regular case: the new component is added after the ticket is created. When the ticket page is reloaded, to update the component, the newly created component does not appear at all in the selection list. Trac is desynchronized:
    • the new component does appear in the webadmin view
    • the new component keeps missing in the ticket view
Trac:	0.12dev-r8139
Python:	2.5.4 (r254:67916, Feb 17 2009, 20:16:45) [GCC 4.3.3]
setuptools:	0.6c9
SQLite:	3.6.13
pysqlite:	2.5.0
Genshi:	0.6dev-r1052
Babel:	-
Pygments:	1.0
Subversion:	1.5.6 (r36142)
jQuery:	1.3.2

Attachments (0)

Change History (6)

comment:1 by Emmanuel Blot, 15 years ago

Owner: set to Remy Blank

comment:2 by Emmanuel Blot, 15 years ago

Note: as expected, reloading Apache solves the cache issue (/etc/init.d/apache2 reload)

in reply to:  description ; comment:3 by Remy Blank, 15 years ago

Status: newassigned

Replying to eblot:

Trac is desynchronized:

  • the new component does appear in the webadmin view
  • the new component keeps missing in the ticket view

That's bad. Is this sporadic, or does it happen every time you add a component? I'm pretty sure I had tested this case, but I must have missed something.

Could you please give me the output of:

SELECT * FROM cache;

in reply to:  3 comment:4 by Emmanuel Blot, 15 years ago

Replying to rblank:

That's bad. Is this sporadic, or does it happen every time you add a component?

Up to now, I've only added two components since the upgrade, and I got the two errors I've described in the ticket description.

Could you please give me the output of:

sqlite> select * from cache;
trac.wiki.api.WikiSystem.pages|0
trac.ticket.api.TicketSystem.fields|0

comment:5 by Remy Blank, 15 years ago

I can only reproduce this the first time around, that is, when the cache table does not yet contain a given cache key. Subsequent additions of components are picked up correctly by other processes.

Was this the first time you added a component (or any new ticket field value) since upgrading your installation to a version of trunk containing the new caching code?

(Mid-air collision)

Ok, so it looks like you had exactly that scenario. Adding new components now should work. I'll fix the initial case, but I don't know yet what's happening.

comment:6 by Remy Blank, 15 years ago

Resolution: fixed
Status: assignedclosed

Ok, fixed in [8158]. The issue was due to a bad ternary operator ersatz. This kind of bug will stop being introduced when we drop Python 2.4 support and we can finally use the real ternary operator ... if ... else ....

Thanks for the bug report!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Remy Blank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Remy Blank to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.