Hoss Man created SOLR-7403:
------------------------------
Summary: auto recoverable snappuller warning should make it more
clear it's addressing problem
Key: SOLR-7403
URL: https://issues.apache.org/jira/browse/SOLR-7403
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Priority: Minor
Aman Tandom recently asked on the mailing list about how to fix/solve/address
warnings like this...
{noformat}
WARN - 2015-04-09 07:11:27.705; org.apache.solr.handler.SnapPuller; File
_p_Lucene50_0.tip did not match. expected checksum is 1515849197 and actual
is checksum 1522458868. expected length is 1188 and actual length is 2409
WARN - 2015-04-09 07:11:27.709; org.apache.solr.handler.SnapPuller; File _
p.si did not match. expected checksum is 2426498564 and actual is checksum
4157813087. expected length is 396 and actual length is 394
{noformat}
..shalin pointed out that although this isn't a "good" situation, it just
indicates a mismatch thta the SnapPuller then goes on to deal with on it's own
via full replication.
We should try to improve log messages like this to inidcate that solr is going
to address this internally. For example: maybe we should append " -
trigggering full replication to automatically recover from this" to the warning
message -- or maybe this should be an INFO level message instead of a WARN? (if
it's an "expected" situation we are cnfident we can deal with automatically)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]