Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 83857 invoked from network); 15 Aug 2009 05:03:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Aug 2009 05:03:47 -0000 Received: (qmail 8831 invoked by uid 500); 15 Aug 2009 05:03:52 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 8735 invoked by uid 500); 15 Aug 2009 05:03:51 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 8724 invoked by uid 99); 15 Aug 2009 05:03:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Aug 2009 05:03:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bryan.j.swift@gmail.com designates 209.85.211.188 as permitted sender) Received: from [209.85.211.188] (HELO mail-yw0-f188.google.com) (209.85.211.188) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Aug 2009 05:03:41 +0000 Received: by ywh26 with SMTP id 26so2594832ywh.5 for ; Fri, 14 Aug 2009 22:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=x/Pt4XLabde5Ejj27cYnpdb2P6m619EvMadIdwqkGNI=; b=U0nqhsBCMEKipvt0OIo4viSfP3x1KwOkw5RTP7+aU5IxwEC00o16QBS4luoX+iqWL2 QpDLIcjKux7jRZ5b75LHPzJxrPXT0tw9SAHH3tXVGCuGpgg02CCy2IZvPP7GZ6F5ug2U GdO8VpqcnVNelLaYWvErYlgVcfv6zxuqs0WYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wuxuJ6zFTvhegoHDBI/2O9BF5cJ/y2B+csinS/EXwBeLWnc6qO9g3WdUyP/i9RX0ag 0318dnjpv/E7kMQyr9j5z086vWcggrZkFm+JZx7cNbCruqfImty2QCGlV/xxW6sNvaiK IhUMHzKSntxJ4O6Wrao4bUkf4JtI8VetVVK5c= MIME-Version: 1.0 Received: by 10.100.154.17 with SMTP id b17mr119258ane.103.1250312600810; Fri, 14 Aug 2009 22:03:20 -0700 (PDT) Date: Sat, 15 Aug 2009 01:03:20 -0400 Message-ID: <182726e80908142203g464f667ek645d9c9cbe2ef00c@mail.gmail.com> Subject: Bytes seem the same but checksums differ From: Bryan Swift To: java-user@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e642d3766df59c04712716ea X-Virus-Checked: Checked by ClamAV on apache.org --0016e642d3766df59c04712716ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'm attempting to create a Directory implementation (lucene-core 2.4.1) to sit on top of Google's App Engine Datastore (written in Scala). In the process of doing this I found something odd for which I'm hoping there is a relatively simple solution. When instantiating a new IndexWriter with my Directory implementation (which uses Datastore based IndexInput and IndexOutput classes) the checksum of the segments file (segments_1 because there is nothing in the index yet) varies when calculated by ChecksumIndexOutput vs ChecksumIndexInput. Of course, this causes a CorruptIndexException to be thrown at line 248. The interesting thing is the array of bytes being written by my DatastoreIndexOutput is the same array of bytes being ready by DatastoreIndexInput. I've also noticed the difference between the checksums is consistently that checksumThen (line 246 in SegmentInfos) is one less than checksumNow (line 245 in SegmentInfos). In an attempt to gain further information about this problem I added CRC32 objects to my IndexInput and IndexOutput definitions to in order to peak in on their values while debugging and it seems the IndexInput and IndexOutput classes I defined have the same checksum after reading and writing all the bits. The source for my implementation to this point can be found at http://github.com/bryanjswift/quotidian/tree/search-checksums under src/main/scala/quotidian/search Any insight or assistance would be very much appreciated at this point. Cheers. Bryan --0016e642d3766df59c04712716ea--