lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] [Commented] (SOLR-2822) don't run update processors twice
Date Wed, 02 May 2012 21:16:49 GMT


Jan Høydahl commented on SOLR-2822:

This idea is very similar to part of what Jan suggested in his comment above...SNIP...but
what i'm thinking of wouldn't require named processors and would be specific to distributed
updates (but wouldn't precluded named processors and more enhanced logic down the road if
someone wanted it).

Yup, that's one way. However, I think we can achieve even more transparency and flexibility
by introducing the concept of *GOTO* in our pipeline! Remember in the old days of programming,
we could jump to a specified place in the code (well, HTML's anchor does the same, but I thought
GOTO was a cooler analogy :) ) 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. The URPChain class
would not know about DistributedUpdateProcessor, but about labels and goto in general.

I like your {{update.distrib=none|toleader|fromleader}} optimization
> 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
> 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