[ https://issues.apache.org/jira/browse/SOLR-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159408#comment-15159408 ]
Scott Blum commented on SOLR-8722: ---------------------------------- [~shalinmangar] is this what you had in mind? We could probably optimize exactly what this code waits on, but I figured I'd just start by reusing the existing code. But looping 320 x 1 second seems a bit excessive for a new core creation. Also, what's the right way to handle things if the remote call fails? Will the code throw before it reaches the wait loop, or should I try to inspect the response object for errors before deciding to wait? I didn't see any special handling at other call sites. > Don't force a full ZkStateReader refresh on every Overseer operation > -------------------------------------------------------------------- > > Key: SOLR-8722 > URL: https://issues.apache.org/jira/browse/SOLR-8722 > Project: Solr > Issue Type: Improvement > Components: SolrCloud > Affects Versions: 5.4.1 > Reporter: Scott Blum > Assignee: Mark Miller > Labels: patch, performance, solrcloud > Attachments: SOLR-8722.patch > > > We're doing an unnecessary ZkStateReader forced refresh on all Overseer > operations. This isn't necessary because ZkStateReader keeps itself up to > date. > According to [~shalinmangar]'s analysis, we just need to put a wait loop at > the end of addReplica to observe the state change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org