[
https://issues.apache.org/jira/browse/SOLR-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278292#comment-13278292
]
Hoss Man commented on SOLR-2822:
--------------------------------
bq. Let's say we create an interface ChainLabel with two methods
getLabel/setLabel, same as your marker but with a nametag. Then
DistribProcessor would set "distrib" as its label, and we could imagine a
future processor which delegates processing to an external pipeline cluster,
which sets another label "externalPipeline". We could even have a dummy noop
UpdateProcessor which sets the label as a config param. Then, you could call
update.chain.goto=myLabel to continue processing at the label
This seems kind of dangerous to me and should probably be fleshed out in it's
own issue with a lot more discussion. As it relates to this particular
problem, it really seems like "skipping to" the distribute update processor
really needs to be independent of any sort of generalized "goto" support that
we might add to the chain, because shouldn't this hypothetical "goto" logic to
work in combination with distributed updates, not in place of it?
ie: if a chain is A->B->DISTRIB->E->F->..., and you send a request to a random
node with "goto=F", then should that randomly selected node really execute F
locally, ignoring the rest of the cloud? it seems like should it forward to a
leader (which may decide to broadcast to all shards, or all leaders if it's a
deleteByQuery) and then they should skip E and goto F ... maybe.
like i said, it seems complicated. i'd rather keep the issue focused for now.
> 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
>
> Attachments: SOLR-2822.patch
>
>
> 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]
