[
https://issues.apache.org/jira/browse/LUCENE-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871224#action_12871224
]
Cservenak, Tamas commented on LUCENE-2476:
------------------------------------------
This is an UT, that 1st _copies_ a known (broken) Index files to a place, and
than tries to use it. Naturally, it fails (since the index files are
corrupted), and then it tries to _recreate_ the index files and recreate the
index content, but it fails to obtain the write lock again. After patch above
applied to 3.0.1, the UT does pass okay.
This is the stack trace I have with vanilla 3.0.1:
{noformat}
org.sonatype.timeline.TimelineException: Fail to configure timeline index!
at
org.sonatype.timeline.DefaultTimelineIndexer.configure(DefaultTimelineIndexer.java:106)
at
org.sonatype.timeline.DefaultTimeline.repairTimelineIndexer(DefaultTimeline.java:79)
at
org.sonatype.timeline.DefaultTimeline.configure(DefaultTimeline.java:60)
at
org.sonatype.timeline.TimelineTest.testRepairIndexCouldNotRead(TimelineTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed
out:
NativeFSLock@/Users/cstamas/worx/sonatype/spice/trunk/spice-timeline/target/index/write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:84)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1045)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:868)
at
org.sonatype.timeline.DefaultTimelineIndexer.configure(DefaultTimelineIndexer.java:99)
... 19 more
{noformat}
> Constructor of IndexWriter let's runtime exceptions pop up, while keeping the
> writeLock obtained
> ------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2476
> URL: https://issues.apache.org/jira/browse/LUCENE-2476
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
> Affects Versions: 3.0.1
> Reporter: Cservenak, Tamas
> Assignee: Michael McCandless
> Priority: Blocker
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2476.patch
>
>
> Constructor of IndexWriter let's runtime exceptions pop up, while keeping the
> writeLock obtained.
> The init method in IndexWriter catches IOException only (I got
> NegativeArraySize by reading up a _corrupt_ index), and now, there is no way
> to recover, since the writeLock will be kept obtained. Moreover, I don't have
> IndexWriter instance either, to "grab" the lock somehow, since the init()
> method is called from IndexWriter constructor.
> Either broaden the catch to all exceptions, or at least provide some
> circumvention to clear up. In my case, I'd like to "fallback", just delete
> the corrupted index from disk and recreate it, but it is impossible, since
> the LOCK_HELD NativeFSLockFactory's entry about obtained WriteLock is _never_
> cleaned out and is no (at least apparent) way to clean it out forcibly. I
> can't create new IndexWriter, since it will always fail with
> LockObtainFailedException.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
