[
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948839#comment-14948839
]
Ishan Chattopadhyaya commented on SOLR-5944:
--------------------------------------------
bq. What happens if the dependent update fails on one shard?
If the dependent update (or even the out of order update) failed on a replica
(isn't this what you meant by "shard"?), I think the leader will put that
replica into LIR.
bq. "leader threads" meaning they are on the leader? If so, this is sort of
where I was going before (handling more on the leader)... except instead of
detecting and waiting for the dependent update, just send the dependent update
first (i.e. don't reorder). Seems easier? Hmmm, but looking at your follow-up,
it sounds more like you're blocking on the replica?
What I meant by "leader threads" was that since at the leader the
DistributedUpdateProcessor distributes these commands to the replicas
synchronously [0], the leader thread will remain blocked till the replica will
not write and return success/failure. However, my intention was, as you point
out, to actually do the wait/"blocking on the replica".
[0] - DistributedUpdateProcessor
{noformat}
for (Node subShardLeader : subShardLeaders) {
cmdDistrib.distribAdd(cmd, Collections.singletonList(subShardLeader),
params, true);
}
{noformat}
(the last boolean being for synchronous)
bq. It certainly is beyond the scope of this ticket, but it also would solve a
lot of issues. We need to continue to think about any and all approaches to
make this feature bullet-proof.
Totally agree. I really want to evaluate doing this, even if not immediately
(unless we absolutely need it for this feature). If there is not a significant
performance loss to using a single channel client to each replica, then this
approach would be really very neat.
bq. Will all "atomic updates" now be handled this way? Seems desirable in
general.
For atomic updates, as they stand today, I think sending only partial document
to the replicas would help if there are lots of fields as we save the cost of
sending and maybe also storage/memory space at the tlog. However, if the other
stored fields require very expensive analysis, it might be better to let the
leader send the full document to the replicas? Is there something else too
which I missed? If we can get in-place updates to work for both numeric and
binary docvalues, I think we'll get one step closer to recommending users to do
all updates this way.
bq. If it hasn't been done already, this could be broken out into it's own
issue and fixed now?
Sure, good catch. I'll create another issue for this.
> Support updates of numeric DocValues
> ------------------------------------
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
> Issue Type: New Feature
> Reporter: Ishan Chattopadhyaya
> Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be
> really nice to have Solr support this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
