Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <28360109.27701272353251896.JavaMail.jira@thor>
Date: Tue, 27 Apr 2010 03:27:31 -0400 (EDT)
From: "Andrzej Bialecki  (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2373) Change StandardTermsDictWriter to
 work with streaming and append-only filesystems
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861281#action_12861281 ] 

Andrzej Bialecki  commented on LUCENE-2373:
-------------------------------------------

Aggregated comments...

Mike: I'd hate to add yet another file just for this purpose. Long-term it's perhaps worth it. Short-term for HDFS use case it would be enough to provide a method to write a header and a trailer. Codecs that can seek/overwrite would just use the header, codecs that can't would use both. Codecs that operate on filesystems with unreliable fileLength could write a sync marker before the trailer, and there could be a back-tracking mechanism that starts from the reported fileLength and then tries to find the sync marker (reading back, and/or ahead).

Shai: hm, but this would require a separate file that stores the header, right?

Lance: yes. The original use case I had in mind was HDFS (Hadoop File System) which already implements on-the-fly checksums. If we go the way that Mike suggested, i.e. implementing a separate codec, then this should be a simple addition. We could also perhaps structure this as a codec wrapper so that this capability can be applied to other codecs too.

> Change StandardTermsDictWriter 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: 3.1
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org