Current Status of Lucene.Net 2.4.0:
All unit tests passes and it is a good candidate for a release.
There are only 2 waiting issues which don't have to be fixed.
1) File Descriptor syncing in FSDirectory.cs
[System.Runtime.InteropServices.DllImport("kernel32")]
public static extern int
FlushFileBuffers(Microsoft.Win32.SafeHandles.SafeFileHandle SafeFileHandle);
public static void Sync(FileStream fs)
{
if (FlushFileBuffers(fs.SafeFileHandle) == 0)
{
throw new SyncFailedException();
}
}
public class SyncFailedException : Exception
{
}
I am not sure about committing this patch. Since it uses InteropServices,
It may cause problems on Mono.
2) Implement Lucene.Net.Store.NIOFSDirectory.cs
(org.apache.lucene.store.NIOFSDirectory.java)
DIGY
-----Original Message-----
From: Doug Sale [mailto:dougs...@gmail.com]
Sent: Tuesday, August 04, 2009 9:58 PM
To: lucene-net-dev@incubator.apache.org
Subject: Status/Todo (all in one place)
The following is my understanding of the current status and remaining
work to be done on the 2.4.0 port:
1) Lucene.Net.Util.CloseableThreadLocal
- Needs WeakReferences wrapping thread-local data.
2)
Lucene.Net.Search.TimeLimitedCollector/Lucene.Net.Search.TestTimeLimitedColl
ector
- Unit tests are failing, requires investigation and bugfix
3) File Descriptor syncing in FSDirectory.cs
FSDirectory.Sync(string) is supposed to sync the underlying file
descriptor, flushing all downstream buffers. I'm not sure how to
accomplish this is C#, and this code needs to be reviewed/fixed/nuked.
Digy suggests the following code fix:
[System.Runtime.InteropServices.DllImport("kernel32")]
public static extern int
FlushFileBuffers(Microsoft.Win32.SafeHandles.SafeFileHandle
SafeFileHandle);
public static void Sync(FileStream fs)
{
if (FlushFileBuffers(fs.SafeFileHandle) == 0)
{
throw new SyncFailedException();
}
}
public class SyncFailedException : Exception
{
}
4) Weak References in Caches
Lucene.Net.Search.CachingSpanFilter.cs
Lucene.Net.Search.CachingWrapperFilter.cs
Lucene.Net.Search.FieldCacheImpl.cs
- Lucene Java utilizes java.util.WeakHashMap
- Lucene.Net is not using a data structure with weak references
Per Digy:
"WeakHashTable(implemented in SupportClass) was used in FieldCacheImpl,
CachingSpanFilter, CachingWrapperFilter in v2.3.2 because HashTable had
caused memory leak
(http://issues.apache.org/jira/browse/LUCENENET-106). But as I said before,
some patches made to Lucene.Net 2.3.2(2.3.1?) are lost with your new 2.4.0"
WeakHashTable needs to be recovered from the 2.3.2 SupportClass and
integrated into the 2.4.0 SupportClass. FieldCacheImpl,
CachingSpanFilter, and CachingWrapperFilter need to be updated to
utilize WeakHashTable.
5) Implement Lucene.Net.Store.NIOFSDirectory.cs
(org.apache.lucene.store.NIOFSDirectory.java)
Me (from a few days ago):
"This is a Java subclass of FSDirectory that allows multiple threads to
read from a single file without blocking each other. Write behavior
is inherited from FSDirectory. If anyone would like to take a stab at
this, please be my guest."
I'm not sure that this is a necessary component for moving forward
with the 2.4.0 release, but if someone comes up with an implementation
that performs better than FSDirectory, of course we would be
interested.
6+) Per Digy: "Here is a list of lost bug fixes/improvements with v2.4.0"
LUCENENET-183
LUCENENET-182
LUCENENET-175
LUCENENET-174
LUCENENET-170
LUCENENET-169
LUCENENET-168
LUCENENET-163
LUCENENET-160
LUCENENET-159
LUCENENET-106 (This is the #4, above)
This list needs to be traversed and ported when/where necessary.
Thanks,
Doug
