lucenenet-dev mailing list archives

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

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

Markus Meyer commented on LUCENENET-186:
----------------------------------------

2) Lucene.Net.Search.TimeLimitedCollector/Lucene.Net.Search.TestTimeLimitedCollector:

The tests are failing because the timer runs too fast, so only the first document will be
hit by the collector.
The cause of the problem is SupportClass.ThreadClass.Sleep(). It calls Thread.Sleep with a
TimeSpan initialized with wrong tick count (10 instead of 10000). But since Thread.Sleep casts
the TimeSpan.GetMilliseconds result to int anyway, one can cast to int in ThreadClass.Sleep
already.

The patch is attached.



> 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