[
https://issues.apache.org/jira/browse/LUCENE-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871236#action_12871236
]
Cservenak, Tamas commented on LUCENE-2476:
------------------------------------------
This is a Lucene index _known_ to be corrupt (got from a "live" Nexus or just
"breaking" it manually by tampering with hex editor, not remember anymore). The
Lucene used to create this index is 2.3.2, so during this UT I believe an index
upgrade happens too.
{noformat}
[INFO] Failed to configure timeline index, trying to repair it.
org.sonatype.timeline.TimelineException: Fail to configure timeline index!
at
org.sonatype.timeline.DefaultTimelineIndexer.configure(DefaultTimelineIndexer.java:107)
at
org.sonatype.timeline.DefaultTimeline.configure(DefaultTimeline.java:49)
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: java.lang.NegativeArraySizeException
at org.apache.lucene.store.IndexInput.readString(IndexInput.java:126)
at org.apache.lucene.index.SegmentInfo.<init>(SegmentInfo.java:173)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:258)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:312)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:677)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:521)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:308)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1076)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:868)
at
org.sonatype.timeline.DefaultTimelineIndexer.configure(DefaultTimelineIndexer.java:100)
... 18 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.0.2, 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]
