lucene-lucene-net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Digy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all in one place)
Date Wed, 05 Aug 2009 20:35:14 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739729#action_12739729
] 

Digy commented on LUCENENET-186:
--------------------------------

Hi Doug,
I can not find the code "TestTimeLimitedCollector". Where is it?

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
>         Attachments: CloseableThreadLocal.cs
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message