[
https://issues.apache.org/jira/browse/SOLR-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266916#comment-13266916
]
Jan Høydahl commented on SOLR-2822:
-----------------------------------
{quote}
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).
{quote}
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: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
