ructure is identical (if not 100% then at least 99%) which in my mind makes
it a more likely candidate for optimization of the fingerprint.
From: dev@solr.apache.org At: 05/05/25 15:57:55 UTC-4:00To: dev@solr.apache.org
Subject: Re: IndexFingerprint and Leader Election Slowness
Ah - I wasn't
y" do run this fingerprint for gigantic TLOG clouds
simply out of superstition. For reference, the fingerprinting feature was added
*before* TLOG+PULL feature so it wouldn't be terribly surprising if this were
an optimization that was still on the table.
>
> Luke
>
> From: dev@s
uot; do run this fingerprint for gigantic TLOG clouds
> simply out of superstition. For reference, the fingerprinting feature was
> added *before* TLOG+PULL feature so it wouldn't be terribly surprising if
> this were an optimization that was still on the table.
>
> Luke
>
perstition. For reference, the fingerprinting feature was added
*before* TLOG+PULL feature so it wouldn't be terribly surprising if this were
an optimization that was still on the table.
Luke
From: dev@solr.apache.org At: 05/05/25 13:27:32 UTC-4:00To: dev@solr.apache.org
Subject: Re: IndexFingerprint an
. This makes me think
> maybe the leader should front load this calculation for its fingerprint
> before asking to "syncToMe" and pass that to each replica to avoid all this
> repeated work and save the network calls.
>
> - Matt
>
> From: dev@solr.apache.org At: 0
Hey all,
Can we talk for a moment about index fingerprinting? For those uninitialized
here is the original ticket https://issues.apache.org/jira/browse/SOLR-8586 as
well as the condition that motivated it
https://issues.apache.org/jira/browse/SOLR-8129.
In short, when a leader fails during dis
