[jira] [Created] (SOLR-7403) auto recoverable snappuller warning should make it more clear it's addressing problem

["Hoss Man (JIRA)" <ji...@apache.org>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org