gerlowskija commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1991496264
##########
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java:
##########
@@ -139,7 +137,8 @@ public CompletableFuture<Rsp> requestAsync(Req req) {
CompletableFuture<Rsp> apiFuture = new CompletableFuture<>();
Rsp rsp = new Rsp();
boolean isNonRetryable =
- req.request instanceof IsUpdateRequest ||
ADMIN_PATHS.contains(req.request.getPath());
+ req.request.getRequestType() == SolrRequestType.UPDATE
Review Comment:
🎉
##########
solr/solrj/src/java/org/apache/solr/client/solrj/request/DelegationTokenRequest.java:
##########
@@ -84,8 +84,8 @@ public DelegationTokenResponse.Get createResponse(SolrClient
client) {
}
@Override
- public String getRequestType() {
- return SolrRequestType.ADMIN.toString();
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
[Q] Unrelated to this PR, but does DelegationTokenRequest serve a purpose
anymore? SOLR-9200 added it originally in order to support 'hadoop-auth', and
now that the "hadoop-auth" module is gone this is only referenced in tests
afaict.
Perhaps it could've been removed when @epugh removed hadoop-auth earlier
this year?
##########
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##########
@@ -185,8 +188,31 @@ public void setQueryParams(Set<String> queryParams) {
this.queryParams = queryParams;
}
- /** This method defines the type of this Solr request. */
- public abstract String getRequestType();
+ /**
+ * Defines the intended type of this Solr request.
+ *
+ * <p>Subclasses should typically override this method instead of {@link
+ * SolrRequest#getRequestType}. Note that changing request type can
break/impact request routing
+ * within various clients (i.e. {@link CloudSolrClient}).
+ */
+ protected SolrRequestType getBaseRequestType() {
+ return SolrRequestType.UNSPECIFIED;
+ }
+
+ /**
+ * Pattern matches on the underlying {@link SolrRequest} to identify ADMIN
requests and other
+ * special cases. If no special case is identified, {@link
SolrRequest#getBaseRequestType()} is
+ * returned.
+ */
+ public SolrRequestType getRequestType() {
+ if (CommonParams.ADMIN_PATHS.contains(getPath())) {
+ return SolrRequestType.ADMIN;
+ } else if (this instanceof IsUpdateRequest) {
Review Comment:
+1 to Luke's comment. We could probably avoid the instanceof check (and
relying on `IsUpdateRequest` entirely) if this method was non-final and we gave
`UpdateRequest` its own implementation:
```
public class UpdateRequest {
public SolrRequestType getRequestType() {
return SolrRequestType.UPDATE;
}
}
```
##########
solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java:
##########
@@ -752,7 +752,7 @@ private Header[] buildRequestSpecificHeaders(final
SolrRequest<?> request) {
new BasicHeader(CommonParams.SOLR_REQUEST_CONTEXT_PARAM,
getContext().toString());
contextHeaders[1] =
- new BasicHeader(CommonParams.SOLR_REQUEST_TYPE_PARAM,
request.getRequestType());
+ new BasicHeader(CommonParams.SOLR_REQUEST_TYPE_PARAM,
request.getRequestType().toString());
Review Comment:
Oh wow, I never noticed we set the "request type" as a header - neat!
##########
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##########
@@ -53,8 +53,9 @@ public ModifiableSolrParams getParams() {
}
@Override
- public String getRequestType() {
- return SolrRequestType.ADMIN.toString();
+ /* This request is not processed as an ADMIN request. */
+ protected SolrRequestType getBaseRequestType() {
+ return SolrRequestType.UNSPECIFIED;
Review Comment:
+1 to avoid any "reclassifying" in this PR.
LukeRequest is in a similar boat IMO (in terms of deserving
reclassification), and there's probably a few others so best to make it a
separate PR/effort.
##########
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##########
@@ -185,8 +188,31 @@ public void setQueryParams(Set<String> queryParams) {
this.queryParams = queryParams;
}
- /** This method defines the type of this Solr request. */
- public abstract String getRequestType();
+ /**
+ * Defines the intended type of this Solr request.
+ *
+ * <p>Subclasses should typically override this method instead of {@link
+ * SolrRequest#getRequestType}. Note that changing request type can
break/impact request routing
+ * within various clients (i.e. {@link CloudSolrClient}).
+ */
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
Yeah, it does seem to complicate the interface a bit.
I'd be fine with the "field" approach that Luke suggested. Or alternately,
could this be solved without even a "field" if `getRequestType` below was
non-final and subclasses could implement it as needed?
##########
solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java:
##########
@@ -55,8 +55,13 @@ public SolrParams getParams() {
}
@Override
- public String getRequestType() {
- return SolrRequestType.UPDATE.toString();
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
[0] Unrelated to this PR, but it's a shame that DirectXmlRequest isn't a
child of either `AbstractUpdateRequest` or `UpdateRequest`. Anyone remember
why this is by chance?
##########
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##########
@@ -210,6 +236,16 @@ public boolean requiresCollection() {
return false;
}
+ /**
+ * Indicates if clients should make attempts to route this request to a
shard leader, overriding
+ * typical client routing preferences for requests. Defaults to true.
+ *
+ * @see CloudSolrClient#isUpdatesToLeaders
+ */
+ public boolean shouldSendToLeaders() {
Review Comment:
The purpose of this PR, as I understand it, is to clean up a lot of the
String pattern matching, casting and instanceof checks from our client
implementations. And the whole "is this an update request and should I route
it to leaders" logic is a big source of those issues.
If you don't like this approach @dsmiley , can you be more explicit about
what alternative path you'd like Jude to take? Are you suggesting this PR not
touch that logic at all? Are you suggesting we remove it altogether in favor
of UpdateRequest setting a `shards.preference` value, or something similar?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
