Trac 0.10.4 requires resync on solaris after every commit

[d1capelis@…]

I poked folks in the #trac channel about this one and they told me to file it. Took me a bit because I was trying to verify again that it isn't my own fault. :) The short summary isn't entirely accurate.... as sometimes with *small* repositories we don't get the error thrown, but large repos still require a resync every time. I just get the dreaded No such revision message (specifying the revision that was just committed) and it doesn't go away until I resync. I've had to install SVN hooks to resync after post-commit to make trac workable for us for now. (Love the software, just this bug tends to really interfere in workflow.) We're running trac on solaris and so it's not as well integrated as it is on linux. Frankly, even after me checking it, the bug might be an installation issue still as we had to do some pretty odd things to get it all installed.

Some details of what it's running:

python 2.3
solaris 9
trac 0.10.4
subversion 1.4.3 + bindings
openidplugin from trac-hacks

Slight code modification that seemed to be necessary with the openid plugin. (found this code change recommended in another bug on a similar issue a few version back) However, I'm pretty sure this isn't the cause of the bug: (Old code commented, my code the line above)

From trac-0.10.4/trac/db/sqlite_backend.py:

        if have_pysqlite == 2:
            self._active_cursors = weakref.WeakKeyDictionary()
            timeout = int(params.get('timeout', 10.0))
            cnx = sqlite.connect(path, detect_types=sqlite.PARSE_DECLTYPES,
                                 check_same_thread=False,
#                                 check_same_thread=sqlite_version < 30301,
                                 timeout=timeout)

Yeah, I know it's a hack, but apparently it was needed...

Anyways, back to the bug. I also get the no such revision found error whenever I view a changeset above a certain size (not sure whether it's number of files or amount of data yet) specifying that it can't find that revision. I don't get this on revisions with only a few changed lines or only a few files. But on commits with lots of things added, it seems to always throw an error, but unlike the symptom described above where after every commit, the entire trac just shows an error, this only happens when you click on a large commit and doesn't go away after a resync.

Thanks folks, keep up the good work. :)

[ThurnerRupert]

we run it for more than 2 yrs now on solaris 8 and 10 and i never saw this. could you give the ​http://blastwave.org version a try?

we noticed trac throwing an exception while trying to display a 250 files all together bigger than 1GB changeset.

[d1capelis@…]

We're using the entire blastwave toolset except for the trac modules themselves which we've compiled against the python2.3 blastwave has. Then we simply installed the 0.10.4 version over the blastwave one. (Which didn't work for us, it couldn't find the subversion bindings.)

[cboos]

Make sure you're using a thread-safe SQLite.
Best is to rebuild it yourself and then rebuild the latest PySqlite (check that page for download and build instructions).

[ThurnerRupert]

we are using default blastwave including sqlite. to my knowledge blastwave compiles the software for sol8, which then runs on 8, 9, 10.

[ThurnerRupert]

marked #5967 as duplicated, this time on ubuntu?

[thatch]

Formatting fix

[sid]

RE: cboos comment:

Make sure you're using a thread-safe SQLite.
Best is to rebuild it yourself and then rebuild the latest PySqlite (check that page for download and build instructions).

Did these suggestions help you out? It has been a while since this ticket was updated, but I don't want to just close it without giving you a little more time to respond.

[d1capelis@…]

My apologies, I thought I had replied to this.

We did rebuild with the latest pysqlite and that didn't seem to help... I'm fairly certain I checked to make sure that the SQLite was threadsafe, but honestly I'm going to have to look again.

We're using a messy system involve SVN hooks for now, so if you want to close this as an installation specific issue I'll file again if these issues are still present in .11? Is anyone else is seeing this problem?

These machines are honestly pretty odd setups, so it may be some obscure library issue.

[anonymous]

Replying to d1capelis@ucsd.edu:

My apologies, I thought I had replied to this.

We did rebuild with the latest pysqlite and that didn't seem to help... I'm fairly certain I checked to make sure that the SQLite was threadsafe, but honestly I'm going to have to look again.

We're using a messy system involve SVN hooks for now, so if you want to close this as an installation specific issue I'll file again if these issues are still present in .11? Is anyone else is seeing this problem?

These machines are honestly pretty odd setups, so it may be some obscure library issue.

We are seeing the same issue here. On a pretty freshly built Solaris 10 machine. I installed trac via pkg-get -i trac . pkg-get said I had some old libraries so wanted me to do a pkg-get upgrade to upgrade all installed packages. I did that and then Trac installed and ran fine. The only issue we are seeing is this resync issue.

[cboos]

Well, using pkg-get don't give you any guarantee that you have the right thread-safe build of SQLite. Please follow the advices given above in comment:3.

[cboos]

Assuming it works with SQLite and pysqlite correctly built.