[
https://issues.apache.org/jira/browse/SOLR-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280455#comment-13280455
]
Mark Miller commented on SOLR-3215:
-----------------------------------
bq. one way to avoid this would be to stop treating the "local" replica as
special
Just to point out explicitly: currently we have to offer this (local is
special) as well though - it's a requirement for our current 'super safe' mode
that we add locally first. So unless we also address some other issues, we'd
have to allow things to happen both ways.
> We should clone the SolrInputDocument before adding locally and then send
> that clone to replicas.
> -------------------------------------------------------------------------------------------------
>
> Key: SOLR-3215
> URL: https://issues.apache.org/jira/browse/SOLR-3215
> 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:
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: [email protected]
For additional commands, e-mail: [email protected]
