jkmuriithi opened a new pull request, #3238: URL: https://github.com/apache/solr/pull/3238
https://issues.apache.org/jira/browse/SOLR-17043 <!-- _(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 Currently, some SolrClient implementations (especially our "load-balancing" and "cloud" clients) do pattern-matching on the path to guess the "type" (admin, update, etc. ) of each request. This seems unnecessary though, as SolrRequest already has a "getRequestType" method exposing this. We should use this method where possible instead of the ad-hoc pattern matching we currently do, which is brittle and doesn't map well to the varied paths used by our v2 APIs. # Solution - Use `SolrRequest.getRequestType` to identify request types in SolrJ, and remove other forms of request type identification from the SolrJ codebase. This includes deprecating the `IsUpdateRequest` interface. - Change `getRequestType` to return the actual `SolrRequestType` enum instead of a String. - Some unit tests use `SolrRequest.setPath()` to send a `QueryRequest` to a `/admin` path. This PR adds basic pattern matching in `getRequestType` and adds method `SolrRequest.getBaseRequestType` to promote an inheritance pattern which works with mutable request paths. - `CloudSolrClient` relies heavily on request type to route requests. After modifying the routing in `CloudSolrClient` to use `getRequestType`, several requests started failing because they returned request type `ADMIN` when their handler path was not in `CommonParams.ADMIN_PATHS`. This PR changes the type of those misclassified requests to `UNSPECIFIED`. Some of these changes may seem counterintuitive (i.e. `/admin/ping` and `/admin/luke` are not `ADMIN` requests), but they preserve the existing data flow. # Tests Solr unit tests pass with `./gradlew test`. # Checklist Please review the following and check all that apply: - [x] 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. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] 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) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [x] 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
