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]

Reply via email to