Skip to content
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

SOLR-17066: Switch ConcurrentSolrClients away from core URLs #2254

Merged

Conversation

gerlowskija
Copy link
Contributor

@gerlowskija gerlowskija commented Feb 8, 2024

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

Description

SOLR-17066 introduced a withDefaultCollection builder method that can be used in lieu of providing a core URL as a "base". (Core URLs are not ideal as they prevent clients from making core-agnostic requests.)

However, Solr's own client usage still needs modified to use this new builder method.

Solution

This commit migrates Solr's "concurrent update" Solr client implementations away from core URLs and towards using withDefaultCollection. Following this PR, the only client that still remains to be migrated are the two "load balancing" clients.)

Tests

Existing tests continue to pass. No new tests needed, as this is "just" a refactor.

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute 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 to contribute to my PR branch. (optional but recommended)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.

SOLR-17066 introduced a withDefaultCollection builder method that can be
used in lieu of providing a core URL as a "base". (Core URLs are not
ideal as they prevent clients from making core-agnostic requests.)
However, Solr's own client usage still needs modified to use this new
builder method.

This commit migrates all ConcurrentUpdateSolrClient usage away from core
URLs and towards using `withDefaultCollection` instead.
SOLR-17066 introduced a withDefaultCollection builder method that can be
used in lieu of providing a core URL as a "base". (Core URLs are not
ideal as they prevent clients from making core-agnostic requests.)
However, Solr's own client usage still needs modified to use this new
builder method.

This commit migrates all LBHttpSolrClient usage away from core
URLs and towards using `withDefaultCollection` instead.
SOLR-17066 introduced a withDefaultCollection builder method that can be
used in lieu of providing a core URL as a "base". (Core URLs are not
ideal as they prevent clients from making core-agnostic requests.)
However, Solr's own client usage still needs modified to use this new
builder method.

This commit migrates all ConcurrentUpdateHttp2SolrClient usage away from core
URLs and towards using `withDefaultCollection` instead.
SOLR-17066 introduced a withDefaultCollection builder method that can be
used in lieu of providing a core URL as a "base". (Core URLs are not
ideal as they prevent clients from making core-agnostic requests.)
However, Solr's own client usage still needs modified to use this new
builder method.

This commit migrates all LBHttp2SolrClient usage away from core
URLs and towards using `withDefaultCollection` instead.

Has a test failure in TestLBHttp2SolrClient that still needs resolved.
Copy link
Contributor

@epugh epugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@@ -83,7 +83,8 @@ private SolrClient buildClient(CloseableHttpClient httpClient, URL url) {
switch (random().nextInt(3)) {
case 0:
// currently, only testing with 1 thread
return new ConcurrentUpdateSolrClient.Builder(url.toString() + "/" + COLLECTION)
return new ConcurrentUpdateSolrClient.Builder(url.toString())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sigh... if only a builder new what a url was and we didn't .tostring everywhere. ;-) #beatdeadhorse

@@ -156,7 +158,7 @@ public void testSimple() throws Exception {
// Start the killed server once again
solr[1].startJetty();
// Wait for the alive check to complete
Thread.sleep(1200);
Thread.sleep(1200 * 5);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1.2 seconds times five?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no memory of this 🤔 - will remove.

@@ -167,17 +169,15 @@ public void testSimple() throws Exception {
}
}

private LBHttp2SolrClient getLBHttp2SolrClient(Http2SolrClient httpClient, String... s) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is nice!

@@ -31,6 +31,8 @@
/** Unit tests for {@link Builder}. */
public class ConcurrentUpdateSolrClientBuilderTest extends SolrTestCase {

private static final String ANY_BASE_URL = "http://localhost:8983/solr";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nicer!

Zombie-resurrection was broken in LBHttp2SolrClient because the default
collection wasn't being taken into account on these requests.  The root
of the problem is the way that LBHttp2 takes in an already-constructed
SolrClient, making it difficult to set the default collection.  (In
contrast, LBHttpSolrClient creates a different client for each base URL
using a common Builder - this allows it to property set the default
collection.)

This commit fixes this by created a 'DelegatingSolrClient' that LBHttp2
can use internally around its single Http2SolrClient.  The default
collection is set on this 'Delegating' wrapper, so that it gets picked
up by the zombie-resurrection logic.
@@ -158,7 +158,7 @@ public void testSimple() throws Exception {
// Start the killed server once again
solr[1].startJetty();
// Wait for the alive check to complete
Thread.sleep(1200 * 5);
Thread.sleep(1200);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The most important code change ;-)

@gerlowskija
Copy link
Contributor Author

Turns out doing this for our 'LB' clients is a little more involved than I initially thought, due to some of the additional public methods they have (e.g. request(LBSolrClient.Req)). I'm going to back the 'LB' changes out of this PR, and focus on only handling our "Concurrent" clients here.

I'll open a separate PR for tackling the LB clients.

@gerlowskija gerlowskija changed the title SOLR-17066: Switch most SolrClients away from core URLs SOLR-17066: Switch ConcurrentSolrClients away from core URLs Feb 14, 2024
@gerlowskija gerlowskija merged commit 6afbc20 into apache:main Feb 14, 2024
3 of 4 checks passed
@gerlowskija gerlowskija deleted the SOLR-17066-cusc-remove-core-urls-pt-1 branch February 14, 2024 17:15
gerlowskija added a commit that referenced this pull request Feb 14, 2024
Providing a core URL as a SolrClient's "base URL" prevents it from
communicating with other cores or making core-agnostic API requests
(e.g. node healthcheck, list cores, etc.)

This commit migrates all usage of both "concurrent update" clients
away from core URLs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants