[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799127#comment-15799127
]
David Smiley commented on SOLR-8030:
------------------------------------
You've read me correctly [~hossman] :-)
I have no idea how controversial ripping this mode of the updateLog out of Solr
would be. To be clear, I propose that the UpdateLog only get written to by
DirectUpdateHandler, and thus we can better reason about it. I've been
following [~caomanhdat] 's progress in SOLR-9835 and the complexities of
PeerSync were too much to deal with so he totally punted on it for now. Was
that related to the fact that the updateLog can be in a buffering mode written
to by DistributedURP? Not sure.
> Transaction log does not store the update chain (or req params?) 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, or any other details from
> the original update request such as the request params, used during updates.
> Therefore tLog uses the default update chain, and a synthetic request, during
> log replay.
> If we implement custom update logic with multiple distinct update chains that
> use custom processors after DistributedUpdateProcessor, or if the default
> chain uses processors whose behavior depends on other request params, then
> log replay may be incorrect.
> Potentially problematic scenerios (need test cases):
> * DBQ where the main query string uses local param variables that refer to
> other request params
> * custom Update chain set as {{default="true"}} using something like
> StatelessScriptUpdateProcessorFactory after DUP where the script depends on
> request params.
> * multiple named update chains with diff processors configured after DUP and
> specific requests sent to diff chains -- ex: ParseDateProcessor w/ custom
> formats configured after DUP in some special chains, but not in the default
> chain
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
