[
https://issues.apache.org/jira/browse/SOLR-15486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383728#comment-17383728
]
David Smiley commented on SOLR-15486:
-------------------------------------
{quote} * Alternatively if waiting for inflight updates to complete (at that
point in the shutdown sequence) is generally beneficial then one could say that
the {{pauseUpdatesAndAwaitInflightRequests}} logic should be added for the
ZK-unware code path in {{CoreContainer.shutdown}} also.{quote}
Makes sense; removes needless SolrCloud specificity. I would word it that way,
not the presence/absence of ZK which is admittedly the typical implementation
detail of how we detect SolrCloud.
> consider SolrCoreState.inflightUpdatesCounter logic in ZK-unware Solr
> ---------------------------------------------------------------------
>
> Key: SOLR-15486
> URL: https://issues.apache.org/jira/browse/SOLR-15486
> Project: Solr
> Issue Type: Task
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
>
> SOLR-14942 added the {{inflightUpdatesCounter}} logic to reduce leader
> election time on node shutdown.
> From my understanding of the code so far:
> * Since the earlier triggering of an election is specific to ZK-aware Solr
> then one could say that {{ContentStreamHandlerBase.handleRequestBody}} doing
> inflight update registers and deregisters is unnecessary.
> * Alternatively if waiting for inflight updates to complete (at that point
> in the shutdown sequence) is generally beneficial then one could say that the
> {{pauseUpdatesAndAwaitInflightRequests}} logic should be added for the
> ZK-unware code path in {{CoreContainer.shutdown}} also.
> Illustrative draft pull request with both options:
> https://github.com/apache/solr/pull/180
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
