[
https://issues.apache.org/jira/browse/SOLR-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Blum updated SOLR-8875:
-----------------------------
Attachment: SOLR-8875.patch
I think this may be a one-liner; in the calling loop, I think there are cases
where you can get all the way to the bottom without having actually written any
updates, which fails to ever initialize ZkStateWriter.clusterState().
To be honest, I'm not a fan of both the Overseer loop and ZkStateWriter both
trying to keep a source-of-truth clusterState variable, it's a recipe for
getting out of sync.
> ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in
> Overseer
> ---------------------------------------------------------------------------------
>
> Key: SOLR-8875
> URL: https://issues.apache.org/jira/browse/SOLR-8875
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: David Smiley
> Attachments: SOLR-8875.patch
>
>
> While trying to get the test in Varun's patch in SOLR-5750 (SolrCloud
> collection backup & restore) to succeed, I kept hitting an NPE in Overseer in
> which clusterState was null. I added a bunch of asserts and found where it
> was happening which I worked around temporarily. See
> https://github.com/apache/lucene-solr/commit/fd9c4d59e8dbe0e9fbd99a40ed2ff746c1ae7a0c#diff-9ed614eee66b9e685d73446b775dc043R247
> which is ZkStateWriter.writePendingUpdates() returning null, overwriting the
> current non-null clusterState. This happens nearly every time for me when I
> run that test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
