id summary reporter owner description type status priority milestone component version severity resolution keywords cc branch changelog apichanges internalchanges 8067 Stopped sync in 0.11.2.1 Christian Boos Christian Boos "As reported by Anatoly on googlegroups:trac-dev:401827e96364f901, there can be situations where versioncontrol cache tables in the database are left in an inconsistent state, from which it is impossible to resume synchronization. ... It turned out to be locked cache after timeout. At first I thought about a race condition, but it was false. The cache can easily be jammed with a long resync from repository on a busy server. It took about 40 seconds to sync 200 revisions before timeout occurred. Take a look at [source:/branches/0.11-stable/trac/versioncontrol/cache.py@7889#L159 cache.py] sync(): On line 159 we check if a revision is being entered in DB by looking if next revision number is already present in `revisions` table. That means another thread is made an INSERT in line 184. The cache is now locked. To unlock it, another thread should update youngest revision at line 221. [[br]] So, the problem is when a timeout occurs during execution of 202:221 - there is an update in `node_change` table that can potentially take a long time to experience a timeout (esp. when server is under a heavy load). There are also cset.get_changes() and self.repos.next_rev(next_youngest) calls that can contribute to the issue. I haven't found other way to recover than to manually patch DB. Also, with a synchronization attempt on every request, this can also lead to a serious slowdown (#7490)." defect closed normal version control 0.11-stable major duplicate cache, postgresql, mysql, pysqlite eric.petit@… techtonik@… dale.miller@…