SOLR-17334: Enable coordinator nodes to handle requests other than `/select`

[tboeghk]

https://issues.apache.org/jira/browse/SOLR-17334

Description

The Solr root resource cannot be requested on a coordinator node Coordinator requests are enabled for the /select handler only From outside proxied and coordinator requests cannot be distinguished.

I built these changes against last weeks main branch. I'll have to adapt to the most recent changes in coordinator handling

Solr root resource

We adopted a general fix from the HttpSolrCall to check whether the given collectionName is null. This fixes requesting the root resource (and maybe other similar requests)

/select handler only

Coordinator requests are limited to the /select handler. In our environment we make heavy usage of pre-configured Solr handlers. We could not find any reason to limit coordinator calls to the /select handler and removed the limitation.

Coordinator requests cannot be identified by Solr response

With any Solr response you cannot distinguish coordinator from proxied (or regular) requests. While this is great for consistency it makes testing extra hard. If tracking debug is enabled, we add an extra debug field called requestCoordinatorNode. This eases testing and debugging a lot.

Tests

This fix lacks tests (yet). As the coordinator setup is quite fresh, it lacks some general tests. Now we're able to distinguish between proxied and coordinator requests and add some tests later.

Checklist

Please review the following and check all that apply:

• [x] I have reviewed the guidelines for How to Contribute 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.
• [ ] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• [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

[noblepaul]

@tboeghk

can you please fix the conflicts ?

[ellaeln]

is there a way to help moving this forward?

[roeeiit1]

This is really important for us, would love to push this fast 🙏

[cpoerschke]

Hello @ellaeln and @roeeiit1 - thanks for your interest in this! One way to help move forward could be to branch off the otto-de:feature/SOLR-17334 branch and merge in the latest origin/main (resolving the merge conflicts) and then open a replacement/continuation pull request from the branched off branch.

[orNagar22]

Very important!

[ellaeln]

Hello @ellaeln and @roeeiit1 - thanks for your interest in this! One way to help move forward could be to branch off the otto-de:feature/SOLR-17334 branch and merge in the latest origin/main (resolving the merge conflicts) and then open a replacement/continuation pull request from the branched off branch.

Ok, thanks. Ill try to get this done shortly

[CommRogue]

This is a shortcoming that affects us too. We are really interested in this getting merged. Thanks! 🙏

[AlmogEinstein]

It is so good to see we are not the only team working on solving this issue! Super relevant and important 🙏

[tboeghk]

Hej everybody. Merging the changes into the current main branch unfortunately means a complete rewrite. But: the changes are sparse so it should be doable with small effort.

I'm eager to do it but it's holiday season and it'll take a couple of weeks 😕.

Until then you can check out Ottos bugfix build at https://github.com/otto-de/solr. This PR is already integrated into the Docker build. That way you can verify the fix in your own environment.

[ellaeln]

Hello @ellaeln and @roeeiit1 - thanks for your interest in this! One way to help move forward could be to branch off the otto-de:feature/SOLR-17334 branch and merge in the latest origin/main (resolving the merge conflicts) and then open a replacement/continuation pull request from the branched off branch.

Ok, thanks. Ill try to get this done shortly

I started working on that and I dont expect running into to many issues on that front. However, this PR will be in conflict with https://github.com/apache/solr/pull/2607 whenever it'll be merged. So I was thinking I'll hold off until 2607 is sorted out and do the merge then. Will that work for you?

[ellaeln]

I opened a draft merge request with the changes of the current main to your branch. https://github.com/otto-de/solr/pull/2 However, it may not be completely finished until https://github.com/apache/solr/pull/2607 is warped up and merged.

[nadavedri]

Super important I hope you will fix it soon!🙏🏻

[AlmogEinstein]

I see #2607 is already merged, @tboeghk - do you think we can move this forward? I see this PR as a game changer for us, coordinator is a must have feature!

[cpoerschke]

I opened a draft merge request with the changes of the current main to your branch. otto-de#2 However, it may not be completely finished until #2607 is warped up and merged.

Thanks @ellaeln for continuing the work started in this pull request!

Would you consider opening a PR to apache:main branch instead of otto-de:feature/SOLR-17334 branch?

[ellaeln]

I have opened a PR to main, https://github.com/apache/solr/pull/2672

please let me know if there's anything I can do to assist further

[tboeghk]

Thanks @ellaeln for picking up the work 🙏 I completely lost track of this during the summer ☀️

However as Solr 9.7 is through the gates, I adapted the coordinator changes to the branch_9_7 baseline in this branch. Shall I update this PR with the new changes?

[ellaeln]

Sure go ahead. I also opened a pr to your branch with 9.7 changes and another one https://github.com/apache/solr/pull/2672 with the both of them combined, feel free to use any of them if you wish

Please let me know if there's anything else I can do to help

[github-actions[bot]]

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 [email protected] 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!

[github-actions[bot]]

This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active again.