jaykay12 commented on code in PR #4955:
URL: https://github.com/apache/solr/pull/4955#discussion_r4319434785
##########
solr/core/src/java/org/apache/solr/cli/CLIUtils.java:
##########
@@ -63,6 +63,16 @@ private CLIUtils() {}
private static final long MAX_WAIT_FOR_CORE_LOAD_NANOS =
TimeUnit.NANOSECONDS.convert(1, TimeUnit.MINUTES);
+ /**
+ * Connect and idle timeouts used for CLI-initiated Solr connections. These
are much shorter than
+ * {@link org.apache.solr.client.solrj.impl.SolrHttpConstants}' defaults,
which are sized for
+ * long-running requests like bulk indexing or replica recovery; a CLI
command run by a human at a
+ * terminal should fail fast instead of hanging for minutes against an
unresponsive node.
+ */
+ public static final int CLI_CONNECTION_TIMEOUT_SECONDS = 3;
+
+ public static final int CLI_IDLE_TIMEOUT_SECONDS = 30;
Review Comment:
My local review agent was against this idea:
Here's what it quoted to me.
> Shortening idle to 30s is not equivalent to “fail fast on a dead node,”
because in SolrJ withRequestTimeout falls back to the idle timeout when unset
(HttpSolrClient.Builder.getRequestTimeoutMillis() → getIdleTimeoutMillis()).
Jetty then applies that value as the total request timeout (req.timeout(...)),
not only as a quiet-socket limit.
> So withIdleTimeout(30, SECONDS) without an explicit longer
withRequestTimeout caps every HTTP round-trip at 30s wall-clock. That replaces
SolrJ’s 600s default and will abort legitimate long CLI work that still has
healthy I/O (export, streaming expressions, postlogs, large posts, package
install, snapshot export, etc.).
> Fail-fast against an unreachable node is a connect timeout concern — 3s
there is right. Leave idle/request at SolrJ defaults (600s) so hung-connect
fails quickly while long-running commands keep working. If we later want a
short idle for “no bytes for N seconds,” we must set withRequestTimeout to
DEFAULT_SO_TIMEOUT (or similar) explicitly so request duration is not coupled
to idle.
--
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]
