[
https://issues.apache.org/jira/browse/SOLR-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14973279#comment-14973279
]
Yonik Seeley commented on SOLR-8203:
------------------------------------
I looped the test overnight (adds only) and there were no shard inconsistency
type fails. Although there were plenty of other fails (50 in fact), this is
the first time that there was no shard inconsistency.
Mark has been testing "interrupt the update executor on shutdown" and that also
looks like it fixes the issue. That will also have the effect of stopping
other operations more quickly (i.e. requests to other nodes that use that
update executor), and in general it seems like a good thing to stop more
quickly. Should that be added here?
> Stop processing updates more quickly on shutdown
> ------------------------------------------------
>
> Key: SOLR-8203
> URL: https://issues.apache.org/jira/browse/SOLR-8203
> Project: Solr
> Issue Type: Bug
> Reporter: Yonik Seeley
> Attachments: SOLR-8203.patch
>
>
> As we discovered in SOLR-8129, existing update streams can continue to be
> processed for some time when the CoreContainer is being shut down. If this
> node is the leader, updates can continue to flow to replicas over the
> existing streaming client (although new or idle clients won't be allowed to
> send anything).
> This can cause large reorders of updates and shard inconsistencies that we
> can't detect with the current PeerSync mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]