-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug Fix: Re-ported ControlledRealTimeReopenThread and added 2 new tests #513
Bug Fix: Re-ported ControlledRealTimeReopenThread and added 2 new tests #513
Conversation
Added two additional demonstration tests for ControlledRealTimeReopenThread that make it easier to see how to use the class. One of the tests, TestMultithreadedWaitForGeneration, demonstrates that the current implemention of the ControlledRealTimeReopenThread class is flawed when used in multi-thread situations. This test will fail currently but I will then add another commit that improves the ControlledRealTimeReopenThread class so that it's a more faithful port of the java version and then the test will pass.
The exising port of ControlledRealTimeReopenThread exhibited threading issues. I constructed a test TestMultithreadedWaitForGeneration which demonstrated the threading issue and falls with the curent port class. To make this test pass I re-ported the ControlledRealTimeReopenThread to more faithly follow the java implementation.
/// </summary> | ||
public void Dispose() | ||
{ | ||
Dispose(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class is not sealed. We should keep the dispose pattern in place so inheritors have a way to dispose any unmanaged resources that they own and so the finalizer doesn't automatically run.
It would also be wise to keep track of whether Dispose(bool)
has been called so it is safe to call it more than once. See https://stackoverflow.com/a/5306896. Also, please include tests for multiple-dispose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll add back a Dispose(bool) method.
Added back a Dispose(bool) method to the ControlledRealTimeReopenThread class since it's a non-sealed class.
…te changes from #513 (#572) * Revert "Revert "Bug Fix: Re-ported ControlledRealTimeReopenThread and added 2 new tests"" This reverts commit 60aef3a. * Lucene.Net.Search.ControlledRealTimeReopenThread: Updated to use Time.SecondsPerNanosecond and Time.MillisecondsPerNanosecond constants rather than literals * Lucene.Net.Search.ControlledRealTimeReopenThread: Made Dispose() lockless and made refreshStartGen and isDisposed atomic * Lucene.Net.Index.ThreadedIndexingAndSearchingTestCase::RunTest(): use using block on LineFileDocs to ensure it is disposed. * Lucene.Net.Search.TestControlledRealTimeReopenThread: Ignore TestStraightForwardDemonstration() and TestMultiThreadedWaitForGeneration(), since they don't play well with other tests due to precision timing * Lucene.Net.Index.ThreadedIndexingAndSearchingTestCase: Use ConucurrentSet<T> rather than ConcurrentHashSet<T>. The latter may have problems with its UnionWith() method. * Lucene.Net.Search.ControlledRealTimeReopenThread: Marked wait handle protected and renamed m_signal so subclasses can receive events * Lucene.Net.Search.ControlledRealTimeReopenThread: Renamed member variable from m_signal to m_notify for clarity * Revert "Lucene.Net.Index.ThreadedIndexingAndSearchingTestCase: Use ConucurrentSet<T> rather than ConcurrentHashSet<T>. The latter may have problems with its UnionWith() method." This reverts commit a93a4a3. * Lucene.Net.Index.IndexReader::Dispose(): Added missing call to GC.SuppressFinalize(this)
Added two additional demonstration tests for ControlledRealTimeReopenThread that make it easier to see how to use the class. One of the tests, TestMultithreadedWaitForGeneration, demonstrates that the current implemention of the ControlledRealTimeReopenThread class is flawed when used in multi-thread situations. This test will fail currently but I will then add another commit that improves the ControlledRealTimeReopenThread class so that it's a more faithful port of the java version and then the test will pass.