vyatkinv opened a new pull request, #4320: URL: https://github.com/apache/solr/pull/4320
https://issues.apache.org/jira/browse/SOLR-18130 <!-- _(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 updates the solrj-streaming module by replacing all usages of zkHost with solrCloud to enable support for HTTP-based quorum configurations. # Solution Parameters, fields and variables in solrj-streaming, named as `zkHost` renamed to `solrCloud` For backward compatibility, specifying zkHost is still supported. A shared method has been introduced in an abstract class to resolve the effective solrCloud value using a priority-based approach (e.g., explicit parameter → legacy zkHost → default Zookeeper host). # Tests To Be Done # 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`. - [ ] 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) - [ ] I have added a [changelog entry](https://github.com/apache/solr/blob/main/dev-docs/changelog.adoc) for my change # Planned follow-ups: - [ ] Perform more thorough testing of solrj-streaming with both Zookeeper-based and HTTP-based quorum configurations - [ ] Add unit tests for HTTP quorum support - [ ] Review and improve error messages and java-doc, where zookeeper still mentioned - [ ] Add documentation and changelog entry # Open Questions / Discussion Points I would appreciate feedback on the following topics (also noted as TODOs in the code): **1. Mandatory solrCloud parameter** I made solrCloud required in all stream handlers (an error is thrown if it cannot be resolved from parameters or the default Zookeeper host). This caused two tests to fail: - `StreamExpressionTest#testCloudSolrStream` - `StreamExpressionTest#testStatsStream` These tests did not provide any valid host. I fixed them by adding `.withDefaultZkHost(cluster.getZkServer().getZkAddress())` _Question:_ - Is this a test issue or a flaw in the implementation? - Can such a situation occur in real-world usage? **2. toExpression behavior and backward compatibility** Currently, toExpression reconstructs the expression and always includes solrCloud, even if the user originally provided the legacy zkHost parameter. As a result, a user who runs an expression with zkHost and then calls explain() will see solrCloud in the output. _Question:_ - Should the original parameter name (zkHost) be preserved? - Or is it acceptable to normalize everything to solrCloud? **3. Potential issue with gather parameter** In: `org/apache/solr/client/solrj/io/graph/GatherNodesStream.java:392` there is the following line: `expression.addParameter(new StreamExpressionNamedParameter("gather", solrCloud));` _Question:_ - Is this a bug? - Or is solrCloud (previously zkHost) actually intended to be passed as gather? **4. Inconsistent parameter handling** Some stream handlers use Map<String, String> for parameters, while others use ModifiableSolrParams. _Question:_ Would it make sense to standardize on a single approach? **5. ScoreNodesStream limitation** `ScoreNodesStream` can only obtain zkHost / solrCloud via: `factory.getDefaultZkHost();` _Question:_ - Should this be improved as part of this PR? - Or would it be better to handle it in a separate issue? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
