[
https://issues.apache.org/jira/browse/SOLR-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-13855.
---------------------------------
Resolution: Fixed
I feel pretty good about what I committed. Unlike pre-Solr-8.1, I simply made
it always propagate finish(). It's not dependent on "nodes" field being null.
I think this is safer and easier to reason about. I suspect nodes could be
non-null and yet documents pass on through due to locally routed docs... yet we
would have failed to propagate finish() then. Run URP's finish does nothing if
no add/delete went through, so I think it's totally fine to always propagate.
RE testing: It'd indeed be nice to test everything gets propagated in the URP
chain but IMO it's even more important that we have a high level test that
checks Solr's integrity. Basically, test the updateLog (or _whatever
mechanism_) is there to save ourselves from failure so that the client can be
assured it doesn't need to re-send documents that were accepted by Solr. I'd
hope we have such a test but we have so many tests that I'm not sure :) Also I
suspect such a high level test would require a "kill -9". It'd take some
effort to create such a test; I doubt we have one actually.
> DistributedZkUpdateProcessor isn't propagating finish()
> -------------------------------------------------------
>
> Key: SOLR-13855
> URL: https://issues.apache.org/jira/browse/SOLR-13855
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
> Affects Versions: 8.1
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In SOLR-12955, DistributedUpdateProcessorFactory was split up into a
> subclass, DistributedZkUpdateProcessor. This refactoring has a bug in which
> finish() is not propagated to the remaining URPs in the chain when
> DistributedZkUpdateProcessor is in play. This is noticeable when
> LogUpdateProcessorFactory is later down the line.
> CC [~barrotsteindev]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
