lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Updated] (SOLR-2822) don't run update processors twice
Date Fri, 18 May 2012 02:52:07 GMT


Hoss Man updated SOLR-2822:

    Attachment: SOLR-2822.patch

Updated patch dealing with all the nocommits and (i think) fixing all the TODO items that
both i and andrzej mentioned, except for...

bq. * includes a randomized test demonstrating the existing problem with doc adds and update
processors both before and after the distrib handler – but this was just shoehorned into
an existing test and should be refactored

I started looking at this and realized that the overhead of creating the cloud instance in
this test was somewhat significant (in terms of wall clock time), so it seemed better to leave
the test method where it was (cleaned up a bit) then to refactor into another test with the
same amount of setup.

bq. * tests don't seem to cover any case that uses requests with TOLEADER set.

the processor skipping code in the chain doesn't care what the value is, or even what type
of requests are processed, so the next test i added in this version of the patch covers both
cases of update.distrib being set or not set.  

The only code path that cares if the values is TOLEADER is in deleteByQuery -- all i did was
ensure that the existing tests where changed to use the new update.distrib param instead of
the old "dbg_level" 

If we need more deleteByQuery tests, that seems like it should be a distinct issue (or at
the very least: an additional patch from someone who udnerstands the distrib tests better
then me.  writing new (whitebox) tests for distribted deleteByQuery is above my solrcloud
foo at this point.)
> 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, 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