Skip to content

Make startJettySolrRunner implicitly wait for node to join cluster#33

Draft
Copilot wants to merge 2 commits intomainfrom
copilot/review-wait-for-node-in-tests
Draft

Make startJettySolrRunner implicitly wait for node to join cluster#33
Copilot wants to merge 2 commits intomainfrom
copilot/review-wait-for-node-in-tests

Conversation

Copy link

Copilot AI commented Mar 19, 2026

MiniSolrCloudCluster.startJettySolrRunner() returned immediately after starting the Jetty process, without waiting for the node to appear in ZooKeeper live nodes. Tests had to explicitly call cluster.waitForNode(jetty, 30) afterward — and many didn't, creating silent race conditions.

Core fix

Added waitForNode(jetty, DEFAULT_TIMEOUT) to both core startJettySolrRunner implementations so all overloads inherit the guarantee:

  • startJettySolrRunner(String name, JettyConfig config, String solrXml) — guarded by solrClient != null since the constructor invokes this in parallel before the client is built (the constructor's existing waitForAllNodes handles that phase)
  • startJettySolrRunner(JettySolrRunner jetty, boolean reusePort) — unconditional; only called post-construction
// Before: caller responsible for synchronization, often forgotten
JettySolrRunner newJetty = cluster.startJettySolrRunner();
cluster.waitForNode(newJetty, 30); // easy to omit → race condition

// After: node is in live nodes by the time the method returns
JettySolrRunner newJetty = cluster.startJettySolrRunner();

Cleanup

Removed now-redundant explicit wait calls from 8 test files:

  • waitForNode(...) after startJettySolrRunner in FullSolrCloudDistribCmdsTest, ClusterEventProducerTest
  • waitForAllNodes(...) immediately after a single startJettySolrRunner in TestMiniSolrCloudClusterSSL, TestCollectionsAPIViaSolrCloudCluster, TestCloudSearcherWarming, TestCloudSolrClientConnections, TestCollectionStateWatchers

waitForAllNodes calls that follow batched/parallel restarts or serve as broader sanity checks are intentionally left in place.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • develocity.apache.org
    • Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -XX:ReservedCodeCacheSize=256m -XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: epugh <22395+epugh@users.noreply.github.com>
Copilot AI changed the title [WIP] Analyze waitForNode usage after startJettySolrRunner Make startJettySolrRunner implicitly wait for node to join cluster Mar 19, 2026
Copilot AI requested a review from epugh March 19, 2026 10:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants