[
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946804#comment-14946804
]
Ishan Chattopadhyaya edited comment on SOLR-5944 at 10/7/15 1:03 PM:
---------------------------------------------------------------------
I was thinking on changing the approach to make sure such inconsistencies
(during recovery, failures etc.) can be avoided. Essentially, I'm thinking of
changing the approach from buffering the inplace updates (as in the last patch)
to, instead, letting leader threads, carrying out of order updates, to wait
till the dependent update has been applied on the replica before the replica
writes the current inplace update to its tlog/index and only then getting an
ACK.
I think, though I may be missing something, the reordered updates would be a
rare occurrence and the delay for the required update to arrive will be in
order of milliseconds, and hence there wouldn't be too much of an overhead to
waiting on those rare occasions.
My initial thought is that doing this will not add any more complexity to log
replays as of today, and the replicas will stay in sync.
[[email protected]] What do you think?
bq. Don't reorder updates between leader and replicas:
Provided the above approach (or some simple variant thereof) works, maybe we
don't absolutely need to do this for supporting inplace updates? I think we
explore this anyway, irrespective of this current issue. I can open another
issue for doing this.
was (Author: ichattopadhyaya):
I was thinking on changing the approach to make sure such inconsistencies
(during recovery, failures etc.) can be avoided. Essentially, I'm thinking of
changing the approach from buffering the inplace updates (as in the last patch)
to, instead, letting leader threads, carrying out of order updates, to wait
till the dependent update has been applied on the replica before writing the
inplace update and only then getting an ACK.
I think, though I may be missing something, the reordered updates would be a
rare occurrence and the delay for the required update to arrive will be in
order of milliseconds, and hence there wouldn't be too much of an overhead to
waiting on those rare occasions.
My initial thought is that doing this will not add any more complexity to log
replays as of today, and the replicas will stay in sync.
[[email protected]] What do you think?
bq. Don't reorder updates between leader and replicas:
Provided the above approach (or some simple variant thereof) works, maybe we
don't absolutely need to do this for supporting inplace updates? I think we
explore this anyway, irrespective of this current issue. I can open another
issue for doing 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: [email protected]
For additional commands, e-mail: [email protected]
