lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-2822) don't run update processors twice
Date Thu, 17 May 2012 21:31:10 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message