lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajiv Delwadia <rajiv.delwa...@versionone.com>
Subject Re: [jira] Closed: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all in one place)
Date Thu, 15 Oct 2009 16:40:32 GMT


On 10/14/2009 1:26 PM, Digy (JIRA) wrote:
>       [ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
>
> Digy closed LUCENENET-186.
> --------------------------
>
>      Resolution: Fixed
>        Assignee: Digy
>
>    
>> Lucene.Net 2.4.0 - Status/Todo (all in one place)
>> -------------------------------------------------
>>
>>                  Key: LUCENENET-186
>>                  URL: https://issues.apache.org/jira/browse/LUCENENET-186
>>              Project: Lucene.Net
>>           Issue Type: Bug
>>             Reporter: Digy
>>             Assignee: Digy
>>          Attachments: CloseableThreadLocal.cs, ReusableStringReader.patch, SupportClass.diff
>>
>>
>> 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.TestTimeLimitedCollector
>> - 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
>>      
>    

Mime
View raw message