Xapian discuss - Jun 2004 - DatabaseCorruptError using CVS Snapshot from 6/17/2004

Well, I *think* we've moved passed the threading/concurrency issues (Xapian
CVS snapshot plus a better synchronization scheme via Java), but now we're
getting this gem:

org.xapian.errors.DatabaseCorruptError: Expected another key with the same
term name but found a different one
        at org.xapian.XapianJNI.writabledatabase_flush(Native Method)

What does this mean?  What causes it?  How do we fix it?

This is occurring with the Xapian CVS snapshot Olly pointed me to last week
(dated 6/17/2004), on our Dual Hyperthreaded Xeon server.

Quartzcheck says the database is just fine:

# /usr/local/bin/quartzcheck xxxxx
record:
base65  Revision *800  levels 2  root [6]  blocksize 8192  items 96842
lastblock 6554
B-tree checked okay
postlist:
base65  Revision *800  levels 2  root [12]  blocksize 8192  items 675806
lastblock 27318
B-tree checked okay
Postlist structure checked OK
termlist:
base65  Revision *800  levels 2  root [15518]  blocksize 8192  items 96841
lastblock 38806
B-tree checked okay
position:
base65  Revision *800  levels 2  root [70427]  blocksize 8192  items
17692647  lastblock 96325
B-tree checked okay
value:
base65  Revision *800  levels 1  root [404]  blocksize 8192  items 96841
lastblock 766
B-tree checked okay

Any ideas?

eric

On Mon, Jun 21, 2004 at 10:23:02AM -0400, Eric B. Ridge
wrote:
> Well, I *think* we've moved passed the threading/concurrency issues
(Xapian
> CVS snapshot plus a better synchronization scheme via Java), but now
we're
> getting this gem:
> 
> org.xapian.errors.DatabaseCorruptError: Expected another key with the same
> term name but found a different one
>         at org.xapian.XapianJNI.writabledatabase_flush(Native Method)
> 
> What does this mean?  What causes it?  How do we fix it?
A long posting list is split into chunks, the last of which has a "this
is the last chunk" flag set.  This error means that there doesn't seem
to be such a "last chunk".
> This is occurring with the Xapian CVS snapshot Olly pointed me to last week
> (dated 6/17/2004), on our Dual Hyperthreaded Xeon server.
I incorrect cleaned up some code (since 0.8.0) which resulted in this
error.  The patch was partly backed out on 17th, and the rest last night
(I failed to notice it didn't cleanly apply the first time - d'oh!)

So try updating to the latest CVS snapshot.
> Quartzcheck says the database is just fine:
That's probably because the exception means that the broken revision never
gets committed.

Cheers,
    Olly