lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3215) We should clone the SolrInputDocument before adding locally and then send that clone to replicas.
Date Wed, 14 Mar 2012 02:00:38 GMT


Mark Miller commented on SOLR-3215:

A couple use cases:

1. You don't want documents to have every processor applied to them twice. Intuitively, you
expect that processors that run after the distrib processor will not hit the document sent
to replicas before the docs are sent to replicas - but it will. Barring future features (like
the JIRA around update chains and solrcloud), there is no way currently to have an update
processor only hit a document once when they go to a replica.

2. When we want to offer the option of adding locally and sending to replicas at the same
time, we still need this, and we don't want to get people used to the current odd behavior
because you couldn't even easily duplicate it (not that i think you'd want to) if you wanted
to add locally and send to replicas in parallel.
> We should clone the SolrInputDocument before adding locally and then send that clone
to replicas.
> -------------------------------------------------------------------------------------------------
>                 Key: SOLR-3215
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Assignee: Mark Miller
>             Fix For: 4.0
>         Attachments: SOLR-3215.patch
> If we don't do this, the behavior is a little unexpected. You cannot avoid having other
processors always hit documents twice unless we support using multiple update chains. We have
another issue open that should make this better, but I'd like to do this sooner than that.
We are going to have to end up cloning anyway when we want to offer the ability to not wait
for the local add before sending to replicas.
> Cloning with the current SolrInputDocument, SolrInputField apis is a little scary - there
is an Object to contend with - but it seems we can pretty much count on that being a primitive
that we don't have to clone?

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