heythm opened a new pull request, #3345: URL: https://github.com/apache/solr/pull/3345
https://issues.apache.org/jira/browse/SOLR-17704 <!-- _(If you are a project committer then you may remove some/all of the following template.)_ Before creating a pull request, please file an issue in the ASF Jira system for Solr: * https://issues.apache.org/jira/projects/SOLR For something minor (i.e. that wouldn't be worth putting in release notes), you can skip JIRA. To create a Jira issue, you will need to create an account there first. The title of the PR should reference the Jira issue number in the form: * SOLR-####: <short description of problem or changes> SOLR must be fully capitalized. A short description helps people scanning pull requests for items they can work on. Properly referencing the issue in the title ensures that Jira is correctly updated with code review comments and commits. --> # Description This PR refactors Solr's distributed lock implementation to use Curator's ZK primitives for all ZooKeeper operations, while preserving the legacy Solr lock semantics. The new implementation, CuratorDistributedLocks, replaces the previous use of Curator's high-level lock recipes and closely matches the behavior of the old ZkDistributedLock, ensuring that read locks are only blocked by lower-numbered write locks and write locks are blocked by any lower-numbered lock. The lock acquisition strategy is documented and explained in the code. # Solution - Introduced a new CuratorDistributedLocks class that uses Curator's CuratorFramework for all ZK operations (node creation, deletion, children listing, and watchers). - The lock acquisition logic matches the legacy Solr semantics: - Read locks only block on lower-numbered write locks. Write locks block on any lower-numbered lock. - The implementation does not sort children or only watch the immediate predecessor, but instead watches the first blocking node found, which may cause more wakeups but is simpler and matches Solr's historical behavior. - Updated the lock factories to use this new implementation and removed the old nested lock logic - Improved documentation and code comments to clarify the design and trade-offs. # Tests - Existing distributed lock tests (e.g., CuratorDistributedLockFactoryTest) were run and pass, confirming that the new implementation preserves the expected semantics. - Manual verification that lock acquisition and release behave as before, including correct exception handling when calling isAcquired() after release(). - No regressions observed in distributed locking behavior. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
