[
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.
