Yep, much nicer ;) This causes one of the testcases that would intermittently fail to now consistently pass, but it looks like this issue is happening elsewhere too, since its failing on the reader writer conflict test. I'm still investigating that but I think it boils down to the same issue. A segments class is renaming segments.new to segments, and the lastModified for that is the same as the previous segments, hence failure.
I'll see if I can come up with a patch for that too, and will hopefully submit a patch with the code below and the other fix tonight. Doug Cutting said: > I think this sort of patch is acceptable: touchFile() is not called in > performance-critical code. One improvement would for it not to > busy-wait, but rather to sleep, i.e.: > > long then = file.lastModified(); > long now = System.currentTimeMillis(); > while (now == then) { > Thread.sleep(1); > now = System.currentTimeMillis(); > } > file.setLastModified(now); > > Doug > > Hani Suleiman wrote: >> Ok, I figured out what's going on. >> >> I suspect this will only manifest itself on faster machines (I'm on a >> dual 1.42ghz G4) >> >> What happens basically is that the the timer resolution on >> file.lastModified isn't accurate enough, so when a file is touched, it >> returns the same value for lastModified. This in turn causes the >> segment staleness checks in IndexReader to fail (around line 276, >> lastModified(directory)==segmentInfosAge), hence the testcase fails. >> >> I believe this is a bug, but I can't come up with a satisfactory >> workaround. My solution is to modify FSDirectory.touchFile(String >> name) to have the following block; >> >> long oldModified = file.lastModified(); >> do >> { >> file.setLastModified(System.currentTimeMillis()); >> } >> while(oldModified==file.lastModified()); >> >> This ensures that a touch ensures the file is considered 'fresher' >> that it was before, which makes everything happy. It's a bit of a >> hack though, so I'm not sure of how you guys would prefer handling >> this, take the performance hit with the extra lastModified checks, >> if make it an even bigger hack by checking for OSX, or something far >> more clever and not detrimental to performance ;) >> >> Hani >> >> On Tuesday, September 30, 2003, at 12:42 AM, Hani Suleiman wrote: >> >>> here you go, happens to me on linux too (with JDK 1.4.0) >>> >>> OSX using latest 1.4.1 >>> >>> [junit] ------------- ---------------- --------------- >>> [junit] Testsuite: org.apache.lucene.index.TestIndexReader >>> [junit] Tests run: 5, Failures: 2, Errors: 0, Time elapsed: 2.883 >>> >>> sec >>> >>> [junit] Testcase: >>> testDeleteReaderWriterConflict(org.apache.lucene.index.TestIndexReader) >>> : FAILED >>> [junit] Delete allowed on an index reader with stale segment >>> information >>> [junit] junit.framework.AssertionFailedError: Delete allowed on >>> an index reader with stale segment information >>> [junit] at >>> org.apache.lucene.index.TestIndexReader.testDeleteReaderWriterConflict( >>> TestIndexReader.java:271) >>> [junit] at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> [junit] at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja >>> va:39) >>> [junit] at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso >>> rImpl.java:25) >>> >>> >>> [junit] Testcase: >>> testDeleteReaderReaderConflict(org.apache.lucene.index.TestIndexReader) >>> : FAILED >>> [junit] Delete allowed from a stale index reader >>> [junit] junit.framework.AssertionFailedError: Delete allowed from >>> >>> a stale index reader >>> [junit] at >>> org.apache.lucene.index.TestIndexReader.testDeleteReaderReaderConflict( >>> TestIndexReader.java:397) >>> [junit] at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> [junit] at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja >>> va:39) >>> [junit] at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso >>> rImpl.java:25) >>> >>> >>> >>> On Tuesday, September 30, 2003, at 12:37 AM, Erik Hatcher wrote: >>> >>>> Hani, >>>> >>>> I don't see this test failure on OS X. Thanks to your patch on the >>>> RussianAnalyzer, all my tests now successfully pass. Could you >>>> give us the stack trace for the problem you're seeing? >>>> >>>> Erik >>>> >>>> >>>> On Monday, September 29, 2003, at 11:28 PM, Hani Suleiman wrote: >>>> >>>>> I'm seeing a fairly disturbing testcase failure on OSX in >>>>> TestIndexReader.testDeleteReaderWriterConflict and >>>>> TestIndexReader.testDeleteReaderReaderConflict >>>>> >>>>> This only happens on OSX though, is this a known issue? Any have an >>>>> ideas of what sort of thing is going wrong before I dig in >>>>> further? >>>>> >>>>> Hani >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] For >>> additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]