We've got this utility TimeOut that assists waiting for a condition to hold in a limited period of time. As a generic utility, of course it involves a sleep period. We use it in many places. IMO it's a sad choice to use when it's possible to alternatively wait on a condition that will wake up the thread. Those who have touched SolrCloud should be aware of ZkStateReader.waitForState, a specific alternative I have in mind.
Say for example, in CreateCollectionCmd https://github.com/apache/solr/blob/cae69c7973303653cade8f9de7b96e26ccd0919e/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L224 There's this: // wait for a while until we see the collection TimeOut waitUntil = new TimeOut(30, TimeUnit.SECONDS, ccc.getSolrCloudManager().getTimeSource()); boolean created = false; while (!waitUntil.hasTimedOut()) { waitUntil.sleep(100); created = ccc.getSolrCloudManager().getClusterState().hasCollection(collectionName); if (created) break; } if (!created) { throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "Could not fully create collection: " + collectionName); } But imagine replacing it with: try { zkStateReader.waitForState(collectionName, 30, TimeUnit.SECONDS, Objects::nonNull); } catch (TimeoutException e) { throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, "Could not fully create collection: " + collectionName, e); } I see other places in "Cmd" classes. We also have CloudUtil.waitForState which uses TimeOut, even for cases clearly based on cluster state :-( Q: Is this replacement fine or am I missing something? TimeSource may be pluggable but it seems sad to forgo waitForState over such a matter. I could file a work item -- should be an easy "newdev" one. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
