SOLR-18243: Refactor solrj-streaming to reuse shared CloudHttp2SolrClient engine#4510
SOLR-18243: Refactor solrj-streaming to reuse shared CloudHttp2SolrClient engine#4510chatzipavlidis wants to merge 1 commit into
Conversation
…lient. Reuse shared cloud http client engine
epugh
left a comment
epugh
left a comment
There was a problem hiding this comment.
Does this need a unit test? Seems like that kind of tricky logic that can go bad in the future!
| baseUrl, | ||
| url -> { | ||
| // Find an existing Cloud Client connection | ||
| HttpSolrClient sharedEngine = this.httpSolrClient; |
There was a problem hiding this comment.
Maybe called it sharedClient?
| // Find an existing Cloud Client connection | ||
| HttpSolrClient sharedEngine = this.httpSolrClient; | ||
|
|
||
| if (sharedEngine == null && !cloudSolClients.isEmpty()) { |
There was a problem hiding this comment.
was cloudSolClients spelled wrong?
There was a problem hiding this comment.
apparently? Should i refactor it?
|
Sorry, this is not what I meant when I filed SOLR-18243. The idea is that most callers of SolrClientCache.getHttpSolrClient should stop doing so -- instead, get a client from the CloudHttp2SolrClient.getHttpClient() that it had moments ago since in most cases, the URL is in fact derived from a CloudSolrClient shard/replica examination. But this may not quite be doable yet because CloudSolrClient.getHttpClient doesn't exist yet. We're blocked from adding this method until #4451 is merged. |
4 participants
Modifies SolrClientCache.java to extract the underlying, shared HTTP client engine from an active CloudHttp2SolrClient connection pool when provisioning stream target connections. This eliminates the creation of isolated, duplicate legacy HttpSolrClient instances across cluster node lookups in solrj-streaming. Verified via StreamExpressionTest debugging sessions.