lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Bialecki (JIRA)" <>
Subject [jira] Updated: (LUCENE-2373) Create a Codec to work with streaming and append-only filesystems
Date Fri, 25 Jun 2010 23:36:51 GMT


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:
>             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.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

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:
For additional commands, e-mail:

View raw message