DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753 Persistent store or cache corruption? [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2004-02-10 17:23 ------- the lockup is caused by a bug in the store version you used (reaquiring a non-reentrant lock). the core bug is a corrupted index caused by a jisp bug regarding b-tree page caching. this is the cause for the exceptions (garbage 'pointer') and also for the wrong content served; using a key which is no longer valid and references the original page it was saved to, you get the next object on that page not marked as deleted. the workaround is to index.emptyPageCache() before AND after modifying operations (clear/remove/store). the attached patch is against 'Avalon_Store_1_0_dev_mavenized' and implements: - AbstractJispFilesystemStore: index.emptyPageCache() around modifying operations, lockup fixed (was already in later CVS) - AbstractFilesystemStore: lockup fixed - AbstractReadWriteStore: write lock changed to read lock in get() while testing the fix I didn't encounter any of the problems described. regarding the testcase (bug #25482) method testClear(), instead of checking the index's count(), it should check the index's key enumeration for emptiness. then it should fail.
