[
https://issues.apache.org/jira/browse/SOLR-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885154#comment-17885154
]
Jason Gerlowski commented on SOLR-17256:
----------------------------------------
Alright - I'd love to make some progress on this, so I wanted to summarize some
of the options in hopes of spurring consensus on a way forward:
# [Http2]SolrClient.request(baseUrl, collection, SolrRequest) - (proposed here)
- Introduce a new "request" method overload that allows callers to specify
their own baseUrl. Less flexible than the current "SolrRequest.setBasePath"
approach, since custom URLs would only be possible when using this specific
method, but it solves the SolrClient/SolrRequest mutability problem nicely.
# [Http2]SolrClient.withBaseUrl(baseUrl) - (proposed here) - would essentially
clone the existing client, only overriding the base URL and making 'close()' a
noop. Nice simple API. Takes advantage of the fact that "Http" SolrClient's
(excepting some of the reusable internals) are cheap to create. That said -
could reusing Executors, etc. be messy? What happens if a "derived" client
outlives its parent?
# [Http2]SolrClient.withBaseUrl(baseUrl, clientConsumingLambda) - Creates a
new client that largely delegates to a wrapped instance, and exposes it for use
in the provided lambda. Current PoC code relies on a ThreadLocal to tunnel
custom URLs into SolrJ's URL-building logic, which is arguably hacky, but this
could be avoided by replacing the client-delegation with client-cloning in a
sort of 2+3 hybrid approach. The lambda sets lifecycle bounds on the derived
client, avoiding some of the potential resource-leak questions that (2) raises.
Have I missed any proposals? These were the ones I could remember. Of those
listed, my personal preference would be for (2) or (3). What do you all think?
One other variable here: what clients should we aim to support URL-overriding
on? Only Http2SolrClient? All of our "Http" SolrClient impls? All of our
SolrClient implementations?
> Remove SolrRequest.getBasePath setBasePath
> ------------------------------------------
>
> Key: SOLR-17256
> URL: https://issues.apache.org/jira/browse/SOLR-17256
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Minor
> Labels: newdev, pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> SolrRequest has a getBasePath & setBasePath. The naming is poor; it's the
> URL base to the Solr node like "http://localhost:8983/solr";. It's only
> recognized by HttpSolrClient; LBSolrClient (used by CloudSolrClient) ignores
> it and will in fact mutate the passed in request to its liking, which is
> rather ugly because it means a request cannot be used concurrently if the
> user wants to. But moreover I think there's a conceptual discordance of
> placing this concept on SolrRequest given that some clients want to route
> requests to nodes *they* choose. I propose removing this from SolrRequest
> and instead adding a method specific to HttpSolrClient. Almost all existing
> usages of setBasePath immediately execute the request on an HttpSolrClient,
> so should be easy to change.
--
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
