Skip to content

Give CLI-initiated Solr connections short, shared connect/idle timeouts - #4955

Open
epugh wants to merge 4 commits into
apache:mainfrom
epugh:SOLR-cli-configurable-timeouts
Open

epugh wants to merge 4 commits into
apache:mainfrom
epugh:SOLR-cli-configurable-timeouts

Conversation

@epugh

@epugh epugh commented Sep 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Spun out of review discussion on a bin/solr create refactor (SOLR-18320): CLI commands that construct a SolrClient via CLIUtils.getSolrClient (or by hand-building an HttpJettySolrClient.Builder) currently inherit SolrHttpConstants' defaults — 60s connect / 600s idle. Those defaults are deliberately generous because they're shared by every SolrJ use case, including bulk indexing, shard-to-shard fan-out, and replica recovery, where a single request can legitimately take minutes.

A human running a bin/solr command at a terminal wants the opposite: fail fast against an unreachable or hung node. DeleteTool already carried its own 15s/30s override for exactly this reason (and CreateTool used to, before a recent refactor accidentally dropped it by switching to the shared client builder).

This PR centralizes that override:

  • Adds CLIUtils.CLI_CONNECTION_TIMEOUT_SECONDS (15) and CLIUtils.CLI_IDLE_TIMEOUT_SECONDS (30).
  • Applies them in CLIUtils.getSolrClient's core builder and in CLIUtils.solrUrlFromConnection's builder, which covers every CLI tool that calls getSolrClient (Healthcheck, SnapshotExport, Version, Assert, Export, Config, Create, Api, Delete, SnapshotList, Package, RunExample, Status, SnapshotCreate, SnapshotDelete).
  • Applies the same constants to the handful of tools that bypass CLIUtils.getSolrClient and hand-build their own HttpJettySolrClient.Builder: DeleteTool (replacing its hardcoded 15/30 with the shared constants), HealthcheckTool, ExportTool, PostLogsTool, StreamTool.

Out of scope: RunExampleTool's two internal waitToSeeLiveNodes/example-bootstrap CloudSolrClient builds are left on the long defaults — those are local-example node-readiness polling loops with their own retry/backoff logic, not a user-facing connection attempt, so a short connect timeout there wouldn't offer the same benefit and risks interacting oddly with the poll loop.

Test plan

  • ./gradlew :solr:core:compileJava — compiles cleanly
  • ./gradlew :solr:core:test --tests DeleteToolTest --tests TestExportTool --tests StreamToolTest --tests CreateToolTest --tests HealthcheckToolTest --tests PostLogsToolTest — all pass (32 tests, 1 skipped)
  • Added a changelog fragment under changelog/unreleased/

🤖 Generated with Claude Code

https://claude.ai/code/session_01HaP4sXv7KQBw9ZEqtvwug2

bin/solr commands funneling through CLIUtils.getSolrClient (and several
that hand-built their own HttpJettySolrClient.Builder) inherited
SolrHttpConstants' 60s connect / 600s idle defaults, which are sized
for long-running SolrJ use cases like bulk indexing and replica
recovery. A human running a CLI command against an unreachable node
wants fast failure instead. Centralizes the 15s/30s timeouts DeleteTool
already used (and CreateTool used to, before a recent refactor moved it
onto the shared client) into CLIUtils.CLI_CONNECTION_TIMEOUT_SECONDS /
CLI_IDLE_TIMEOUT_SECONDS, and applies them everywhere a CLI tool builds
an HttpJettySolrClient.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HaP4sXv7KQBw9ZEqtvwug2
@epugh

epugh commented Sep 27, 2026

Copy link
Copy Markdown
Contributor Author

This was claude generated, but looking hrtorugh, it seem sto make sense. I don't know if we want to have a single place to configure hte client, feels like we have gone and back and forth on this....

epugh added 2 commits October 7, 2026 15:49
…le-timeouts

# Conflicts:
#	solr/core/src/java/org/apache/solr/cli/DeleteTool.java
@epugh
epugh requested a review from janhoy October 7, 2026 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant