Skip to content

Conversation

@imotov
Copy link
Contributor

@imotov imotov commented Sep 16, 2015

The cluster state updates from underlying clusters are now updated in batches, which should improve the cluster change propagation performance. Related to #12814.

@bleskes
Copy link
Contributor

bleskes commented Sep 18, 2015

@imotov talked this one through I feel the code will be much simpler (with less added components) if we use the recently added PendingClusterStatesQueue per incoming cluster. An update would then need to poll all the queues for their next states, process that and that's it. The queue already manages batching.

 The cluster state updates from underlying clusters are now updated in batches, which should improve the cluster change propagation performance. Related to elastic#12814.
@imotov imotov force-pushed the tribe-node-batch-processing branch from d89fb49 to e39eb39 Compare October 8, 2015 22:11
@imotov
Copy link
Contributor Author

imotov commented Oct 8, 2015

@bleskes I refactored the batch processing. It's still work in progress, more tests are needed and I need to convert other batch tasks into the new mode. But I just want to make sure that I understood you correctly before I jump too deep into it.

@bleskes
Copy link
Contributor

bleskes commented Oct 25, 2015

@imotov thx! What I had in mind is extract the executor part out of the cluster state update task, so you’d have a task to do and another executor to apply multiple of those tasks. The semantics would be that all tasks with the same executor can be run in batch. This is very similar to this PR.

To see whether this would work I took your PR and started playing and I ended breaking the update task into 4 roles:

  • The info needed for the task (arbitrary object, like your param)
  • Configuration (priority, timeout etc.)
  • Executor
  • Listener

I made all of those interfaces so they can be combined at will (and not having to worry about multiple inheritance) and made the ClusterSTateUpdateTask implement all 3 and have Void as the param of task. This mean that all existing code just compiled :)

Then I took MetaDataMappingService as a use case and removed all local batching and implemented it using the new stuff. It worked pretty well, I think. I even re-introduce batching on the mapping update calls needed for indexing (which removed in the work towards 2.0, see #10720).

It’s all here: https://github.com/elastic/elasticsearch/compare/master...bleskes:cluster_state_batch?w=1

I made it so it will be very easy to port to 2.1. I think it’s important because of the mapping update batching. Let me know what you think

@clintongormley
Copy link
Contributor

Closing in favour of #14993

@imotov imotov deleted the tribe-node-batch-processing branch May 1, 2020 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants