Skip to content

Conversation

@martijnvg
Copy link
Member

I had to make a few unrelated changes to the ccr stats and pause APIs. In case a follower index has been removed and we keep the shard follow tasks around then we have no way to read stats from these tasks or pause them, because the requests are routed based on the follower index.

@martijnvg martijnvg added WIP :Distributed Indexing/CCR Issues around the Cross Cluster State Replication features labels Oct 11, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left one comment, looks good otherwise.

.collect(Collectors.toList());

if (shardFollowTaskIds.isEmpty()) {
listener.onFailure(new IllegalArgumentException("no shard follow tasks [" + request.getFollowIndex() + "]"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no shard follow tasks -> no shard follow tasks for

@martijnvg martijnvg added >non-issue and removed WIP labels Oct 11, 2018
@martijnvg martijnvg merged commit f7df871 into elastic:master Oct 16, 2018
tlrx added a commit to tlrx/elasticsearch that referenced this pull request Jul 24, 2019
Deleting a follower index does not delete its ShardFollowTasks, potentially
leaving many persistent tasks in the cluster that cannot be allocated on
nodes and unnecessary fill the logs. This commit adds a cluster state listener
(ShardFollowTaskCleaner) that completes (with a failure) any persistent task
that refers to a non existent follower index.

I think that this bug has been introduced by elastic#34404: before this change the
task would have been completed as failed and removed from the cluster state.
tlrx added a commit to tlrx/elasticsearch that referenced this pull request Jul 24, 2019
Deleting a follower index does not delete its ShardFollowTasks, potentially
leaving many persistent tasks in the cluster that cannot be allocated on
nodes and unnecessary fill the logs. This commit adds a cluster state listener
(ShardFollowTaskCleaner) that completes (with a failure) any persistent task
that refers to a non existent follower index.

I think that this bug has been introduced by elastic#34404: before this change the
task would have been completed as failed and removed from the cluster state.
tlrx added a commit that referenced this pull request Jul 25, 2019
Deleting a follower index does not delete its ShardFollowTasks, potentially
leaving many persistent tasks in the cluster that cannot be allocated on
nodes and unnecessary fill the logs. This commit adds a cluster state listener
(ShardFollowTaskCleaner) that completes (with a failure) any persistent task
that refers to a non existent follower index.

I think that this bug has been introduced by #34404: before this change the
task would have been completed as failed and removed from the cluster state.

Backport of #44702 and #44801 on 7.x
tlrx added a commit that referenced this pull request Jul 25, 2019
Deleting a follower index does not delete its ShardFollowTasks, potentially
leaving many persistent tasks in the cluster that cannot be allocated on
nodes and unnecessary fill the logs. This commit adds a cluster state listener
(ShardFollowTaskCleaner) that completes (with a failure) any persistent task
that refers to a non existent follower index.

I think that this bug has been introduced by #34404: before this change the
task would have been completed as failed and removed from the cluster state.

Backport of #44702 and #44801 to 7.3
tlrx added a commit that referenced this pull request Jul 25, 2019
Deleting a follower index does not delete its ShardFollowTasks, potentially
leaving many persistent tasks in the cluster that cannot be allocated on
nodes and unnecessary fill the logs. This commit adds a cluster state listener
(ShardFollowTaskCleaner) that completes (with a failure) any persistent task
that refers to a non existent follower index.

I think that this bug has been introduced by #34404: before this change the
task would have been completed as failed and removed from the cluster state.

Backport of #44702 and #44801 on 6.8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Indexing/CCR Issues around the Cross Cluster State Replication features >non-issue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants