You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2017/11/07 21:58:00 UTC
[jira] [Commented] (SOLR-11616) Backup failing on a constantly
changing index with NoSuchFileException
[ https://issues.apache.org/jira/browse/SOLR-11616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242983#comment-16242983 ]
Hoss Man commented on SOLR-11616:
---------------------------------
1) Repeating here some key comments i just made in SOLR-9120 since there are very relevant...
{quote}
And FWIW: The more i read up on all of these issues: No one has ever actually posted any explicit logs, or steps to reproduce, of any failures with backup (or ReplicationHandler) to this (SOLR-9120) issue (or for that matter: to SOLR-8587, or to SOLR-8793, *OR* to SOLR-11616) ... AFAICT there is only anecdotal information claiming that these exceptions (logged by LukeRequestHandler) are also a "similar problem" to doing backups/replication.
If anyone has can provide *Actual logs* from an error occuring during backup/replication -- along with configs / steps to reproduce: SOLR-11616 is the place to post them.
AFAIK there is *NO* code in LukeRequestHandler that is used by any backup/replication based code -- it is purely for _status_ purposes.
{quote}
2) specifically in regards to the current SOLR-11616.patch ...
bq. Completely untested patch copying the solution that was used in SOLR-9120
To be very clear: there is no indication/evidence that this is a "solution" to anything -- the patch that this "copies" from very much does not address the fundmental source of the NoSuchFileExceptions in SOLR-9120
3) Before we go considering changes to which IndexCommit point the backup code looks at, it would be nice to have:
* some actual logs w/stack traces showing an actual problem
* some details of how to reproduce (even if vague or not 100% reproducible) the problem that manifested those logs/exceptions
* an explanation -- in words -- as to *why* folks _feel_ like changing the source of the IndexCommit used by SnapShooter is "more correct" then the current code
** ideally i'd love to see a formal proof (w/junit test) that *proves* the patch is "correct" but i'll settle for an explanation of a feeling
> Backup failing on a constantly changing index with NoSuchFileException
> ----------------------------------------------------------------------
>
> Key: SOLR-11616
> URL: https://issues.apache.org/jira/browse/SOLR-11616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
> Assignee: Varun Thacker
> Attachments: SOLR-11616.patch
>
>
> As reported by several users on SOLR-9120 , Solr backups fail with NoSuchFileException on a constantly changing index.
> Users linked SOLR-9120 to the root cause as the stack trace is the same , but the fix proposed there won't fix backups to stop failing.
> We need to implement a similar fix in {{SnapShooter#createSnapshot}} to fix the problem
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org