[
https://issues.apache.org/jira/browse/SOLR-15735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837723#comment-17837723
]
Yohann Callea edited comment on SOLR-15735 at 4/16/24 1:51 PM:
---------------------------------------------------------------
If it can root for the need to support v2 APIs in SolrJ, it is worth mentioning
that some APIs introduced with Solr 9 are v2 only, without a v1 counterpart.
These v2 only APIs do not seem to be handled properly when called from the
(generated) client in SolrJ, which is quite unsettling from a SolrJ user's
perspective.
To illustrate this behavior, let's take the BalanceReplicas API as an example.
I will simply call it using the _ClusterApi.BalanceReplicas_ client exposed in
SolrJ in
[BalanceReplicasTest|https://github.com/apache/solr/blob/main/solr/core/src/test/org/apache/solr/cloud/BalanceReplicasTest.java#L102-L105]
in place of _postDataAndGetResponse(...)_ so it is reproducible.
{code:java}
BalanceReplicas req = new BalanceReplicas();
req.setWaitForFinalState(true);
req.process(cloudClient); {code}
Such call is consistently throwing {*}_SolrException: No collection param
specified on request and no default collection has been set: []_{*}, as we are
unexpectedly falling in the following else section of
[CloudSolrClient|https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java#L1028-L1064]
:
{code:java}
if (request instanceof V2Request) {
if (!liveNodes.isEmpty()) {
List<String> liveNodesList = new ArrayList<>(liveNodes);
Collections.shuffle(liveNodesList, rand);
final var chosenNodeUrl = Utils.getBaseUrlForNodeName(liveNodesList.get(0),
urlScheme);
requestEndpoints.add(new LBSolrClient.Endpoint(chosenNodeUrl));
}
} else if (ADMIN_PATHS.contains(request.getPath())) {
for (String liveNode : liveNodes) {
final var nodeBaseUrl = Utils.getBaseUrlForNodeName(liveNode, urlScheme);
requestEndpoints.add(new LBSolrClient.Endpoint(nodeBaseUrl));
}
} else { // Typical...
Set<String> collectionNames = resolveAliases(inputCollections);
if (collectionNames.isEmpty()) {
throw new SolrException(
SolrException.ErrorCode.BAD_REQUEST,
"No collection param specified on request and no default collection has
been set: "
+ inputCollections);
}
[...]
}{code}
I would not expect a SolrJ user to tinker with its SolrCloudClient to change
the path prefix from /solr to /api to make it work in this situation.
Maybe SolrJ should expose API clients leveraging V2Request for these specific
APIs, as it would then work just fine :
{code:java}
V2Request req =
new V2Request.Builder("cluster/replicas/balance")
.forceV2(true)
.POST()
.withPayload(Map.of(WAIT_FOR_FINAL_STATE, true))
.build();
req.process(cloudClient);
{code}
was (Author: JIRAUSER303849):
If it can root for the need to support v2 APIs in SolrJ, it is worth mentioning
that some APIs introduced with Solr 9 are v2 only, without a v1 counterpart.
These v2 only APIs do not seem to be handled properly when called from the
(generated) client in SolrJ, which is quite unsettling from a SolrJ user's
perspective.
To illustrate this behavior, let's take the BalanceReplicas API as an example.
I will simply call it using the _ClusterApi.BalanceReplica_ client exposed in
SolrJ in
[BalanceReplicasTest|https://github.com/apache/solr/blob/main/solr/core/src/test/org/apache/solr/cloud/BalanceReplicasTest.java#L102-L105]
in place of _postDataAndGetResponse(...)_ so it is reproducible.
{code:java}
BalanceReplicas req = new BalanceReplicas();
req.setWaitForFinalState(true);
req.process(cloudClient); {code}
Such call is consistently throwing {*}_SolrException: No collection param
specified on request and no default collection has been set: []_{*}, as we are
unexpectedly falling in the following else section of
[CloudSolrClient|https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java#L1028-L1064]
:
{code:java}
if (request instanceof V2Request) {
if (!liveNodes.isEmpty()) {
List<String> liveNodesList = new ArrayList<>(liveNodes);
Collections.shuffle(liveNodesList, rand);
final var chosenNodeUrl = Utils.getBaseUrlForNodeName(liveNodesList.get(0),
urlScheme);
requestEndpoints.add(new LBSolrClient.Endpoint(chosenNodeUrl));
}
} else if (ADMIN_PATHS.contains(request.getPath())) {
for (String liveNode : liveNodes) {
final var nodeBaseUrl = Utils.getBaseUrlForNodeName(liveNode, urlScheme);
requestEndpoints.add(new LBSolrClient.Endpoint(nodeBaseUrl));
}
} else { // Typical...
Set<String> collectionNames = resolveAliases(inputCollections);
if (collectionNames.isEmpty()) {
throw new SolrException(
SolrException.ErrorCode.BAD_REQUEST,
"No collection param specified on request and no default collection has
been set: "
+ inputCollections);
}
[...]
}{code}
I would not expect a SolrJ user to tinker with its SolrCloudClient to change
the path prefix from /solr to /api to make it work in this situation.
Maybe SolrJ should expose API clients leveraging V2Request for these specific
APIs, as it would then work just fine :
{code:java}
V2Request req =
new V2Request.Builder("cluster/replicas/balance")
.forceV2(true)
.POST()
.withPayload(Map.of(WAIT_FOR_FINAL_STATE, true))
.build();
req.process(cloudClient);
{code}
> SolrJ should fully support Solr's v2 API
> ----------------------------------------
>
> Key: SOLR-15735
> URL: https://issues.apache.org/jira/browse/SOLR-15735
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2
>
> Having our v2 API exercised by our test suite would provide a needed boost of
> confidence and serve to flush out any existing gaps. Doing this though
> requires that the v2 API is exposed through SolrJ, since SolrJ is mostly what
> our tests are based on.
> This ticket serves as an umrella to track whatever works ends up being
> necessary for updating SolrJ to use the V2 API. At a minimum, this will need
> to include updating individual SolrRequest objects to use a v2 API, and
> ensuring that SolrClient's offer the same optimizations in routing, etc. to
> v2 requests as they do for v1.
> One open question that'll impact the scope of this work significantly is
> whether SolrJ must support v1 and v2 simultaneously, or whether individual
> SolrRequest implementations can be switched over to v2 without retaining v1
> support. (See discussion of this
> [here|https://issues.apache.org/jira/browse/SOLR-15141?focusedCommentId=17435576&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17435576]).
--
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
