[
https://issues.apache.org/jira/browse/LUCENE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-2373:
--------------------------------------
Attachment: appending.patch
This patch contains an implementation of AppendingCodec and necessary
refactorings in CodecProvider and SegmentInfos to support append-only
filesystems. There is a unit test that illustrates the use of the codec and
verifies that it works with append-only FS.
Note 1: SegmentInfos write/read methods used the seek/rewrite trick to update
the checksum, so it was necessary to extend CodecProvider with methods to
provide custom implementations of SegmentInfosWriter/Reader (and default
implementations thereof).
Note 2: o.a.l.index.codecs.* doesn't have access to many package-level APIs
from o.a.l.index.*, so I had to relax the visibility of some methods and
fields. Perhaps this may be tightened back in a later revision...
Patch is relative to the latest trunk (rev. 958137).
> Create a Codec to work with streaming and append-only filesystems
> -----------------------------------------------------------------
>
> Key: LUCENE-2373
> URL: https://issues.apache.org/jira/browse/LUCENE-2373
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Andrzej Bialecki
> Fix For: 4.0
>
> Attachments: appending.patch
>
>
> Since early 2.x times Lucene used a skip/seek/write trick to patch the length
> of the terms dict into a place near the start of the output data file. This
> however made it impossible to use Lucene with append-only filesystems such as
> HDFS.
> In the post-flex trunk the following code in StandardTermsDictWriter
> initiates this:
> {code}
> // Count indexed fields up front
> CodecUtil.writeHeader(out, CODEC_NAME, VERSION_CURRENT);
> out.writeLong(0); // leave space for end
> index pointer
> {code}
> and completes this in close():
> {code}
> out.seek(CodecUtil.headerLength(CODEC_NAME));
> out.writeLong(dirStart);
> {code}
> I propose to change this layout so that this pointer is stored simply at the
> end of the file. It's always 8 bytes long, and we known the final length of
> the file from Directory, so it's a single additional seek(length - 8) to read
> it, which is not much considering the benefits.
--
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]
