lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-3215) We should clone the SolrInputDocument before adding locally and then send that clone to replicas.
Date Mon, 21 May 2012 19:49:41 GMT


Hoss Man commented on SOLR-3215:

bq. What about the sig update proc or others that do something like modify the updateTerm
on the update command - this type of thing does not get distributed as we turn update commands
into update requests, and the mapping doesn't cover updateTerm.

that seems like a complicity distinct problem ... as i mentioned in SOLR-3473, the distrib
update proc really needs to be aware of all properties of the AddUpdateCommand and serializes/deserialize
that info when forwarding to the leader (and all of the replicas) .. in the case of "updateTerm"
it's not even enough to make sure the shard leader and all replicas know about it -- other
docs in other shards might also need to be deleted.
> 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