-
Notifications
You must be signed in to change notification settings - Fork 1
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
SOLR-17015: Test and fix bug in MoveReplicaCmd for PRS collections #155
base: fs/branch_9_3
Are you sure you want to change the base?
Conversation
backported from in-process upstream PR at: (cherry picked from commit 34c289b4f91a1eb18c851049c74558ab4c4de600)
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.
LGTM!
@@ -149,11 +147,6 @@ public synchronized boolean onStateChanged(Set<String> liveNodes, DocCollection | |||
log.debug("-- already done, exiting..."); | |||
return true; | |||
} | |||
if (collectionState.getZNodeVersion() == lastZkVersion) { |
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.
Do we need this check for non-prs collection?
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.
Just want to confirm my understanding, this check did not work for PRS enabled collection because PRS entries change would not update the zNodeVersion, hence PRS updates are ignored and the watch can stall because it never sees the active replica?
If that's the case, i'm wondering if we can check both the node and the child version if collectionState.isPerReplicaState()
is true
?
I looked at the original change of this and it's a part of a pretty big PR so I don't know the importance of this check (like did we really see alot of spurious calls?). But erring on the safe side, perhaps we can keep it and make it work for PRS too :) ?
As for reference, I searched message that contains seconds for replica to become active
(AddReplica
timeout if this was an issue) on BQ solros nodes (sep and oct), so far we don't have any hits yet.
But regardless, this is definitely an issue for PRS enabled collections and need to be fixed! 😊
boolean matches = predicate.matches(n, c); | ||
if (matches) latch.countDown(); | ||
if (matches) { | ||
docCollection.set(c); |
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.
We may need to keep this outside? what if condition doens't match and timeout happens below. We are accessing collection below
throw new TimeoutException(
"Timeout waiting to see state for collection="
+ collection
+ " :"
+ docCollection.get());
backported from in-process upstream PR at:
(cherry picked from commit 34c289b4f91a1eb18c851049c74558ab4c4de600)
See: https://issues.apache.org/jira/browse/SOLR-17015