-
Notifications
You must be signed in to change notification settings - Fork 809
SOLR-17712 : Deprecate CommonAdminParams.waitForFinalState and make it true default #3684
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
base: main
Are you sure you want to change the base?
SOLR-17712 : Deprecate CommonAdminParams.waitForFinalState and make it true default #3684
Conversation
solr/solr-ref-guide/modules/deployment-guide/pages/collection-management.adoc
Show resolved
Hide resolved
solr/api/src/java/org/apache/solr/client/api/model/BalanceReplicasRequestBody.java
Show resolved
Hide resolved
|
@dsmiley Changes as per the review. |
dsmiley
left a comment
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.
Thanks; excellent! I'll merge tomorrow night at the earliest.
|
Looks like there are test failures. I suggest finding the one that looks the simplest and look into it further. If you need help, LMK. |
|
@dsmiley Mostly all the watchers are failing to complete or to fulfil the replica requirement. I might need help to which watcher to utilise in this case.
This is from addreplicacmd. |
|
Should be deprecated: |
…nalState_default_true # Conflicts: # solr/CHANGES.txt
|
I debugged one test -- TestPullReplica. The test intentionally created a replica that would have issues becoming fully active. That aspect was easy -- switch from |
(add replica, move replica, migrate, replace, balance)
dsmiley
left a comment
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 spent half the day investigating / fixing what I think is the last of the difficult tests; a collection restore test. What remains are a handful of tests that just check messages and need to be updated simply (I assume merely by looking at test method names). @abumarjikar could you handle those please?
The lock matter needs to be discussed more... I'll at-mention Houston for that.
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.
quite a few SolrCloud commands directly call AddReplicaCmd...
| if (collectionState.getZNodeVersion() == lastZkVersion | ||
| && Objects.equals(lastPrs, collectionState.getPerReplicaStates())) { |
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.
PRS wasn't working with waitForFinalState until this
| RequestStatusState state = RequestStatusState.NOT_FOUND; | ||
| while (System.nanoTime() < finishTime) { | ||
| state = this.process(client).getRequestStatus(); | ||
| RequestStatusResponse response = this.process(client); |
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 just wanted this on its own line so that in a debugger we can easily see what the response payload has
| ADDREPLICAPROP(true, LockLevel.NONE), // nocommit discuss | ||
| DELETEREPLICAPROP(true, LockLevel.NONE), // nocommit discuss |
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.
@HoustonPutman I wonder what your opinion is here. We've got one test org.apache.solr.cloud.TestPullReplica#testSkipLeaderRecoveryProperty that purposefully adds a replica that isn't happy and then sets a property (SKIP_LEADER_RECOVERY_PROP) that leads to it being happy. I removed the lock level, which made the test pass so that it doesn't block on addReplica's happiness (final state). That's not my reasoning to remove the lock level... I'm wondering it it's harmless to let replica properties be set on any replica at any time?
Maybe ideally the waitForFinalState should happen outside the LockLevel but that would be tricky as it amounts to a design change to command processing, giving commands a final stage outside the lock.
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.
Discussed in dev list. I'm inclined to have these be NONE. And add an upgrade ref guide note about BALANCESHARDSUNIQUE to advise not to change the property during running that command (duh).
For that matter... no reason not to do likewise for manipulating a collection property.
Please enter the commit message for your changes. Lines starting
…ate_default_true' into SOLR_17712_remove_waitForFinalState_default_true
…tForFinalState_default_true # Conflicts: # solr/CHANGES.txt
|
Hey @dsmiley I have fixed the remaining test cases |
| for (Pair<CollectionAction, List<String>> operation : operations) { | ||
| final Lock lock = session.lock(operation.first(), operation.second()); | ||
| if (lock != null) { | ||
| if (lock != null && !lock.equals(LockTree.FREELOCK)) { |
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.
curious what's going on here? (and with orderOfExecutionChanges)
|
I think a sync from main is in order |
|
This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the dev@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution! |
https://issues.apache.org/jira/browse/SOLR-17712
Description
This PR targets to Deprecate CommonAdminParams.waitForFinalState and make it true default
Solution
Please provide a short description of the approach taken to implement your solution.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.