[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849260#comment-17849260
]
Sanjay Dutt edited comment on SOLR-16503 at 5/24/24 11:00 AM:
--------------------------------------------------------------
First look tells me that SolrClientCache is unnecessarily creating
Http2SolrClient, every time someone calls SolrClientCache#getHttpSolrClient. It
may be because of custom timeouts,
However, I believe that UpdateShardHandler and SolrClientCache both are using
60secs(HttpClientUtil.DEFAULT_SO_TIMEOUT,
HttpClientUtil.DEFAULT_CONNECT_TIMEOUT) for both socket and connection timeout.
So there is no need to re-create the client again from the default client.
Unless someone change the UpdateShardHandler timeouts to something else. I
wonder If we can fix these values for default client globally so that we do not
have to re-create.
{code:java}
public synchronized SolrClient getHttpSolrClient(String baseUrl) {
ensureOpen();
Objects.requireNonNull(baseUrl, "Url cannot be null!");
if (solrClients.containsKey(baseUrl)) {
return solrClients.get(baseUrl);
}
final SolrClient client;
if (apacheHttpClient != null) {
client = newHttpSolrClient(baseUrl, apacheHttpClient);
} else {
client = newHttp2SolrClientBuilder(baseUrl, http2SolrClient).build();
}
solrClients.put(baseUrl, client);
return client;
}{code}
Note :- SolrClientCache has not started returning Http2SolrClient yet because
It's still initialized with Apache Http client in CoreContainer.
was (Author: JIRAUSER305513):
First look tells me that SolrClientCache is unnecessarily creating
Http2SolrClient, every time someone calls SolrClientCache#getHttpSolrClient. It
may be because of custom timeouts,
However, I believe that UpdateShardHandler and SolrClientCache both are using
60secs(HttpClientUtil.DEFAULT_SO_TIMEOUT,
HttpClientUtil.DEFAULT_CONNECT_TIMEOUT) for both socket and connection timeout.
So there is no need to re-create the client again from the default client.
Unless someone change the UpdateShardHandler timeouts to something else. I
wonder If we can fix these values for default client globally so that we do not
have to re-create.
{code:java}
public synchronized SolrClient getHttpSolrClient(String baseUrl) {
ensureOpen();
Objects.requireNonNull(baseUrl, "Url cannot be null!");
if (solrClients.containsKey(baseUrl)) {
return solrClients.get(baseUrl);
}
final SolrClient client;
if (apacheHttpClient != null) {
client = newHttpSolrClient(baseUrl, apacheHttpClient);
} else {
client = newHttp2SolrClientBuilder(baseUrl, http2SolrClient).build();
}
solrClients.put(baseUrl, client);
return client;
}{code}
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -------------------------------------------------------------
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
> Reporter: David Smiley
> Priority: Major
> Attachments: Screenshot 2024-03-16 at 9.14.36 PM.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
> ----
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
