-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Optimize TaskBatcher behavior in case of a datacenter failure. #41407
Conversation
* Replace the global synchronized lock with ConcurrentMap facilities * Faster duplicate task check in the common case
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.
I left a code style review comment.
server/src/main/java/org/elasticsearch/cluster/service/TaskBatcher.java
Outdated
Show resolved
Hide resolved
Pinging @elastic/es-distributed |
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.
Have you benchmarked the approach here and checked whether it works better under high contention?
if (duplicateTask != null) { | ||
throw new IllegalStateException("task [" + duplicateTask.describeTasks( | ||
Collections.singletonList(existing)) + "] with source [" + duplicateTask.source + "] is already queued"); | ||
LinkedHashMap::new)); |
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.
why LinkedHashMap? Do you care about insertion order?
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.
I have been trying to understand that and I am not 100% sure that we should or should not care.
The insertion order was maintained in the original version with the help of LinkedHashSet
though and I was not brave enough to relax the semantics.
I have not benchmarked the approach here, but noticed that all |
Ok, I would prefer for you to try out 6.4.0+ first then, as I'm a bit on the fence that the changes here are needed (or whether we can get away with something much simpler, e.g. just a faster check for task duplicates). |
Closes #41406:
synchronized(tasksPerBatchingKey)
with fine-grainedConcurrentMap
facilitiesTaskBatcher
functional behavior (ordered tasks with identity) remains intactTested in production using
v5.6.11
release.CLA signed.
gradle check
passed.