[
https://issues.apache.org/jira/browse/LUCENE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1094:
---------------------------------------
Attachment: LUCENE-1094.patch
Attached patch. I plan to commit in a day or two.
I added a test case showing the issue & confirming the fix.
I also made a small improvement to the bulk-copy stored fields during
merge optimization: the segment to be merged does not have to have
identical fieldName -> number mappings as the merged segment.
Instead, it just has to be a subset, ie, the fieldName -> number
mapping for all fieldNames in the segment to be merged must match.
It's OK when the merged segments has additional fields beyond this.
> Exception in DocumentsWriter.addDocument can corrupt stored fields file (fdt)
> -----------------------------------------------------------------------------
>
> Key: LUCENE-1094
> URL: https://issues.apache.org/jira/browse/LUCENE-1094
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 2.3
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 2.3
>
> Attachments: LUCENE-1094.patch
>
>
> DocumentsWriter writes the number of stored fields, up front, into the
> fdtLocal buffer. Then, as each field is processed, it writes each
> stored field into this buffer. When the document is done, in a
> finally clause, it flushes the buffer to the real fdt file in the
> Directory.
> The problem is, if an exception is hit, that number of stored fields
> can be too high, which corrupts the fdt file.
> The solution is to not write it up front, and instead write only the
> number of fields we actually saw.
--
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]
