[
https://issues.apache.org/jira/browse/SOLR-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125317#comment-13125317
]
Jan Høydahl commented on SOLR-2822:
-----------------------------------
Nice thought to allow modeling the flow in the update-chain itself as an
intuitive way of choosing which processing to do on the receiving node, on the
leader node, or on each replica:
{code}
A-UP -> B-UP -> Distrib-UP(leader) -> C-UP -> Distrib-UP(replica) -> D-UP ->
Run-UP
{code}
The Distrib processor could set some state info on the request to the next node
so that chain processing could continue where it left off. E.g.
&update.chain.nextproc=<name/id-of-next-proc>. This would require introduction
of named processor instances.
The default if no distrib explicitly specified could be to run
Distrib-UP(leader) prior to the chain and Distrib-UP(replica) right before
Run-UP? See SOLR-2370. In a non-cloud setting, the Distrib-UPs would do nothing.
> don't run update processors twice
> ---------------------------------
>
> Key: SOLR-2822
> URL: https://issues.apache.org/jira/browse/SOLR-2822
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud, update
> Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> An update will first go through processors until it gets to the point where
> it is forwarded to the leader (or forwarded to replicas if already on the
> leader).
> We need a way to skip over the processors that were already run (perhaps by
> using a processor chain dedicated to sub-updates?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
