[
https://issues.apache.org/jira/browse/SOLR-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193951#comment-17193951
]
Cao Manh Dat commented on SOLR-14776:
-------------------------------------
> Is there a chance that the core is changing between subsequent calls and so
> it is not safe to use the same, maybe from incoming updates?
During leader election there shouldn't be any updates coming from the old
leader (we are not doing anything to prevent that), if there are the current
fingerprint strategy's here is also fail
> It looks like there is already caching on SolrCore.getIndexFingerprint, is
>that broken or insufficient in some way?
Yeah, but we only compute fingerprint during leader election. Therefore after a
very heavy indexing, then the leader goes away the first call to fingerprint
gonna takes awhile then slowdown the leader election
> Thinking about this more, is the big win that we compute our own fingerprint
>during the time that would normally be spent waiting, and we decrease latency
>that way?
This can be a way to do that, another solution here is on commit the segment we
already compute fingerprint for that segment, but I think it is worth to do in
another issue.
> Precompute the fingerprint during PeerSync
> ------------------------------------------
>
> Key: SOLR-14776
> URL: https://issues.apache.org/jira/browse/SOLR-14776
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Computing fingerprint can very costly and take time. But the current
> implementation will send requests for getting fingerprint for multiple
> replicas, then on the first response it will then compute its own fingerprint
> for comparison. A very simple but effective improvement here is compute its
> own fingerprint right after send requests to other replicas.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
