Prevent Duplicate ILM Cluster State Updates from Being Created#78390
Prevent Duplicate ILM Cluster State Updates from Being Created#78390original-brownbear merged 4 commits intoelastic:masterfrom original-brownbear:dedup-ilm
Conversation
WIP, deduplicating these tasks.
|
Pinging @elastic/es-data-management (Team:Data Management) |
probakowski
left a comment
There was a problem hiding this comment.
Thanks @original-brownbear, this change looks good. I left just one question and small suggestion.
I tested this locally and with creating 1000 indices at the same time and tasks count (_cat/pending_tasks) never went above 5000 comparing to 1000000 without this change.
| } | ||
|
|
||
| private boolean registerTask(IndexLifecycleClusterStateUpdateTask task) { | ||
| synchronized (executingTasks) { |
There was a problem hiding this comment.
any reason for explicit synchronized block and not using Collections.synchronizedSet(new HashSet<>()) or ConcurrentHashMap?
There was a problem hiding this comment.
Right ... not sure why I did it this used the sync set now and just inlined everything since it's all one liners now :)
Thanks!
| final boolean removed; | ||
| synchronized (executingTasks) { | ||
| removed = executingTasks.remove(task); | ||
| } | ||
| assert removed : "tried to unregister unknown task [" + task + "]"; |
There was a problem hiding this comment.
| final boolean removed; | |
| synchronized (executingTasks) { | |
| removed = executingTasks.remove(task); | |
| } | |
| assert removed : "tried to unregister unknown task [" + task + "]"; | |
| synchronized (executingTasks) { | |
| final boolean removed = executingTasks.remove(task); | |
| assert removed : "tried to unregister unknown task [" + task + "]"; | |
| } |
probakowski
left a comment
There was a problem hiding this comment.
LGTM, thanks @original-brownbear!
|
Thanks @probakowski ! |
… (#78427) Prevent duplicate ILM tasks from being enqueued to fix the most immediate issues around #78246. The ILM logic should be further improved though. I did not include `MoveToErrorStepUpdateTask` in this change yet as I wasn't entirely sure how valid/safe hashing/comparing arbitrary `Exception`s would be. That could be looked into in a follow-up as well. Relates #77466 Closes #78246
Follow up to #78390. The `EmptyInfo` would not compare correctly because it doesn't implement equals or hashcode, breaking deduplication for `SetStepInfoUpdateTask`. => just making it a singleton to fix this and have a fast comp via instance equality.
Follow up to #78390. The `EmptyInfo` would not compare correctly because it doesn't implement equals or hashcode, breaking deduplication for `SetStepInfoUpdateTask`. => just making it a singleton to fix this and have a fast comp via instance equality.
If the current combination of current-step and index has a running CS update task enqueued there is no point in adding yet another task for this combination on the applier and we can skip the expensive inspection for the index. follow up to #78390
If the current combination of current-step and index has a running CS update task enqueued there is no point in adding yet another task for this combination on the applier and we can skip the expensive inspection for the index. follow up to #78390
Prevent duplicate ILM tasks from being enqueued to fix the most immediate issues around #78246. The ILM logic should be further improved though. I did not include
MoveToErrorStepUpdateTaskin this change yet as I wasn't entirely sure how valid/safe hashing/comparing arbitraryExceptions would be. That could be looked into in a follow-up as well.Relates #77466
Closes #78246