lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8030) Transaction log does not store the update chain (or req params?) used for updates
Date Fri, 25 May 2018 18:17:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491116#comment-16491116
] 

Shawn Heisey commented on SOLR-8030:
------------------------------------

I was thinking that if we could move Atomic Update processing out of DistributedUpdateProcessor
into its own processor, we could cover almost every situation that requires a post-processor.
 But there may be a complication to doing that -- the core that runs pre-processors (is that
a valid term?) may be for the wrong shard, and possibly for the wrong collection, so accessing
the original document that's being updated could be a problem.


> 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
>            Priority: Major
>         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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message