[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221824#comment-15221824
]
David Smiley commented on SOLR-8030:
------------------------------------
Thanks Ludovic. Yesterday on IRC #solr-dev [~shalinmangar] described this to
me in more detail. At least with this understanding, I can tweak my update
chain configuration accordingly. I added a healthy dose of comments to the
config & URP code I have, and some safety checks.
IMO, separately from this issue, I claim this aspect of SolrCloud would be
better off if DistributedURP didn't write to the UpdateLog. It complicates
things quite a bit that it does, both the code readability/maintainability and
trying to reason about when URPs run. Instead I think the DistributedURP
should block during recovery or perhaps return an informative error (or first
then second). Adding URP chain metadata to the UpdateLog as the title suggests
is more technical debt & complexity, even if it seems to fix URPs to always run
exactly once. I think fixing technical debt is a challenge for open-source...
it's harder than adding another band-aid but we're better off in the long run.
That's how it was when I set out to add BC dates to Solr when I discovered our
date handling code was using obsolete date APIs. Band aids, in the short term,
are less work.
> Transaction log does not store the update chain used for updates
> ----------------------------------------------------------------
>
> Key: SOLR-8030
> URL: https://issues.apache.org/jira/browse/SOLR-8030
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.3
> Reporter: Ludovic Boutros
> Attachments: SOLR-8030.patch
>
>
> Transaction Log does not store the update chain used during updates.
> Therefore tLog uses the default update chain during log replay.
> If we implement custom update logic with multiple update chains, the log
> replay could break this logic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
