-
Notifications
You must be signed in to change notification settings - Fork 626
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
TaskMergeScheduler: Salvage or deprecate? #354
Comments
If there's already a faster and more stable implementation with |
The only reason to consider keeping But if someone were willing to step up and make |
Sounds like a challenge! I'll tweet it out and see if there's any takers :) |
Given that #381 doesn't seem to solve our issue and we have had no other takers, it looks like it is time to deprecate [Obsolete("Use ConcurrentMergeScheduler instead. This class will be removed in 4.8.0 release candidate."), System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public class TaskMergeScheduler : MergeScheduler, IConcurrentMergeScheduler As part of the deprecation, we need to tear out the We can also remove the tests for Although it wasn't part of Lucene, we can leave the |
…rrentMergeSchedulerFactories class from the public API and its use from all tests (see apache#354)
…rrentMergeSchedulerFactories class from the public API and its use from all tests (see #354)
TaskMergeScheduler
was originally created to sidestep issues with limited multithreading support on .NET Standard 1.x. However, since we have dropped support for .NET Standard 1.x, it is no longer technically a requirement. While having a merge scheduler based on TPL sounds like a brilliant idea, in its current incarnation it falls considerably short of where it needs to be to be included in the release.ConcurrentMergeScheduler
.Lucene.Net.Index.TestTaskMergeScheduler::TestSubclassTaskMergeScheduler()
test occasionally fails (see Known Failing Tests on Lucene.Net #269).TaskMergeScheduler
has been removed from being randomly injected into tests in the test framework because of the negative performance impact it has on test runs.I have fixed a few bugs with it, including the fact it was failing to re-throw a background merge failure, a requirement for
IndexWriter
to retry.The main performance issue stems from the fact that it uses
ToArray()
to copy its_mergeThreads
collection when looping. An attempt was made to replace the collection withConcurrentHashSet<T>
and removeToArray()
on each loop, but at least one of the tests starts failing with that change.So, my question is should we attempt to salvage it, or deprecate it? By deprecate, I mean it will be marked obsolete in the next beta and deleted from the project in the first release candidate.
If someone wants to take a stab at either fixing it or redesigning it, it is fair game. This could be an opportunity to add a more performant alternative to
ConcurrentMergeScheduler
to the project. If it performs adequately and provides the correct behavior, we will consider making it the default.The text was updated successfully, but these errors were encountered: