[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8030:
---------------------------
Description:
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
was:
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.
Summary: Transaction log does not store the update chain (or req
params?) used for updates (was: Transaction log does not store the update
chain used for updates)
FWIW: I have not looked into this issue in depth, nor have i had time to really
read & think about the patch posted -- but based on some recent discussion
about this issue and SOLR-9883 it occured to me that the problem is almost
cerainly broader then just keeping track of the chain name -- it's also
potentially all the request params from the original request.
So i've updated the summary & description accordingly.
> 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]
