Varun Thacker created SOLR-12246:
------------------------------------
Summary: Any full recovery complains about checksum mismatch for a
.liv file
Key: SOLR-12246
URL: https://issues.apache.org/jira/browse/SOLR-12246
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker
Any time a full recovery happens, I get a failed checksum mismatch on the
".liv" file.
{code:java}
date time WARN
[recoveryExecutor-3-thread-5-processing-x:collection_shard_replica
https:////host:port//solr//collection_shard_replica r:core_node69
n:host:port_solr c:collection s:shard] ? (:) - File _2yzfn_7pc.liv did not
match. expected checksum is 4263266717 and actual is checksum 1689291857.
expected length is 936757 and actual length is 936757{code}
Today we download the file anyways because of this check in IndexFetcher
{code:java}
static boolean filesToAlwaysDownloadIfNoChecksums(String filename,
long size, CompareResult compareResult) {
// without checksums to compare, we always download .si, .liv, segments_N,
// and any very small files
return !compareResult.checkSummed && (filename.endsWith(".si") ||
filename.endsWith(".liv")
|| filename.startsWith("segments_") || size < _100K);
}{code}
So I think a WARN here is very confusing to a user who doesn't understand the
internals of a full recovery .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
