lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Digy" <digyd...@gmail.com>
Subject RE: Lucene.NET 2.4.0
Date Wed, 04 Mar 2009 17:02:02 GMT
Hi George,

Where do you thing to apply the patch v2.3.2 to? \tags\Lucene.Net_2_3_1 or
trunk(which will be 2.4.0 I think)

DIGY

-----Original Message-----
From: George Aroush [mailto:george@aroush.net] 
Sent: Wednesday, March 04, 2009 1:29 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: Lucene.NET 2.4.0

Hi Doug,

Thanks for working on the port, I know it's a lot of work, and I'm sure
everyone here appreciates it.

My suggestion is, you commit this code to the truck so the community can
have a look, but first create a new tag (\tags\Lucene.Net_2_3_1\) and move
the existing code from trunk to it.  If you are unsure how this is done, let
me know.

Once the code is in SVN, we can start reviewing, fixing, and stabilizing it.

Btw, one of the "tests" that I do is use the test code from the earlier
release against the newly ported code.  This will tell me if I have created
any API divergence.

Regards,

-- George
 

> -----Original Message-----
> From: Doug Sale [mailto:dougsale@gmail.com] 
> Sent: Friday, February 27, 2009 10:15 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Lucene.NET 2.4.0
> 
> As I mentioned prior (
> http://mail-archives.apache.org/mod_mbox/incubator-lucene-net-
> dev/200812.mbox/browser),
> I've been working on the 2.4.0 conversion of Lucene to 
> Lucene.NET.  I'd like to discuss making the code publicly 
> available for folks to both use and work on, as it it almost 
> complete.  There are a handful of things to be ironed out, 
> which I've listed below.  Of course, patches to 2.3.x 
> codebase prior to release will have to be considered/made to 
> the 2.4.0 codebase in parallel.
> 
> 
> Failing Unit Tests
> 
> 1) TestIndexReaderReopen.TestThreadSafety
> - issue w/ norms being set in highly contentious index
> 
> 2) TestIndexWriter.TestAddIndexOnDiskFull
> - issue w/ intermediate segment field infos file not being 
> deleted (_1.fnm) after merge
> 
> ~) TestHugeRamFile.TestHugeFile
> - this isn't really a failing unit test, but is included for 
> sake of completeness
> - as has been covered prior, simple reduce the memory usage 
> of the test to a reasonable size for your machine and the 
> test runs fine (otherwise, an
> OutOfMemoryException)
> 
> 
> Unimplemented New Classes
> 
> 1) NIOFSDirectory.cs
> - is there something similar to the java.nio package that C# provides?
> 
> 2) TimeLimitedCollector.cs
> - also, TestTimeLimitedCollector.cs
> - no impediment to doing these, just not done
> 
> 
> Other Unaddressed Features
> 
> 1) FileDescriptor Syncing
> - 2.4.0 uses a "Commit" model for indexes and attempts to 
> flush data to disk via a file descriptor synchronization
> - FSDirectory.Sync(string file) (used by IndexWriter.cs, 
> SegmentInfos.cs, and DirectoryIndexReader.cs when an index is 
> Committed)
> - is there a C# equivalent of java.io.FileDescriptor.sync()?
> - will this require a workaround?
> 
> 2) WeakReferences
> - have not implemented weak references where they are used in Lucene
> - (in Cache classes and where java.util.WeakHashMap is used)
> - does the CLR have the same garbage-collection issues as the Java VM?
> 
> 3) Index Checksums
> - implemented API (ChecksumIndexInput.cs, 
> ChecksumIndexOutput.cs), but stubbed-out checksum generation
> - i'm assuming that the Lucene checksum (using 
> java.util.zip.CRC32) is the standard CRC-32 algorithm (ISO 
> 3309, ISO/IEC 13239:2002, ITU-T V.42)
> - in order to use indexes across Lucene and Lucene.NET, we'll 
> need to use the same algorithm (and same polynomial table) as 
> Lucene (from the java.util.zip API) in order to satisfy 
> built-in checks in SegmentInfos.Read(Directory, string)
> 


Mime
View raw message