You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by "Digy (JIRA)" <ji...@apache.org> on 2009/08/04 22:09:14 UTC
[jira] Created: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all
in one place)
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
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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739667#action_12739667 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-168 ok.
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
>
> 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.
[jira] Updated: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all
in one place)
Posted by "Markus Meyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Meyer updated LUCENENET-186:
-----------------------------------
Attachment: SupportClass.diff
> 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, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all
in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Digy updated LUCENENET-186:
---------------------------
Attachment: ReusableStringReader.patch
I found another patch that got lost with 2.4.0. LUCENENET-150.
I changed the patch a little bit and comitted.
All unit test pass.
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, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739637#action_12739637 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-170 & LUCENENET-174 ok.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739622#action_12739622 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-159 & LUCENENET-160 ok.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739668#action_12739668 ]
Digy commented on LUCENENET-186:
--------------------------------
Hi Doug,
I think, 4) and 6+) fixed.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739629#action_12739629 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-163 ok.
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
>
> 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.
[jira] Updated: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all
in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Digy updated LUCENENET-186:
---------------------------
Attachment: CloseableThreadLocal.cs
Hi Doug,
Can you test this CloseableThreadLocal class?
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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739191#action_12739191 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-106 patched.
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
>
> 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.
Re: [jira] Closed: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by Rajiv Delwadia <ra...@versionone.com>.
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
>>
>
[jira] Closed: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo (all
in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739634#action_12739634 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-169 ok.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739646#action_12739646 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-183 ok.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741138#action_12741138 ]
Digy commented on LUCENENET-186:
--------------------------------
SupportClass.ThreadClass.Sleep patched. Thanks Markus.
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, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739141#action_12739141 ]
Digy commented on LUCENENET-186:
--------------------------------
Starting with a simple one, LUCENENET-182 for v2.4.0 patched.
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
>
> 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741423#action_12741423 ]
Digy commented on LUCENENET-186:
--------------------------------
CloseableThreadLocal patched.
Current Status of this Issue:
Fixes waiting to be done:
3) File Descriptor syncing in FSDirectory.cs
5) Implement Lucene.Net.Store.NIOFSDirectory.cs
(org.apache.lucene.store.NIOFSDirectory.java)
All others are fixed.
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, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Markus Meyer (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (LUCENENET-186) Lucene.Net 2.4.0 - Status/Todo
(all in one place)
Posted by "Digy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739642#action_12739642 ]
Digy commented on LUCENENET-186:
--------------------------------
LUCENENET-175 ok.
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
>
> 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.