[
https://issues.apache.org/jira/browse/SOLR-11892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16338762#comment-16338762
]
Erick Erickson commented on SOLR-11892:
---------------------------------------
I'm not being clear. Forget all about deleteIfExists, I agree that it doesn't
help. Forget about optimizations, I'm over that too.
The remaining question for me is code correctness. We seem to be trying to
delete files that don't exist. That raises the possibility that somewhere the
bookkeeping is off, or there's a race condition or... Was a decision made that
any such bookkeeping issues (if they in fact exist) can safely be ignored or
are handled appropriately? And/or performance would suffer if underlying issues
were addressed?
We don't see bad indexes or ever-growing numbers of file handles and I'm
certain this is not new, nor is it a crisis. I do wonder if we're catching
exceptions and driving on, masking underlying issues.
Another way to say it is to ask if, in your view, does the existence of these
exceptions raise any concerns about the correctness of the code that's trying
to delete files that don't exist and generating them?
I'll attach a couple of screen shots for an indexing load test over a one
minute time frame showing over 2,600 such exceptions. Unix file system. These
are from 6.6.2, but I'm reasonably sure I saw the same things in master, if
this Jira is worth pursuing I can double-check.
> Avoid unnecessary exceptions in FSDirectory and RAMDirectory
> ------------------------------------------------------------
>
> Key: SOLR-11892
> URL: https://issues.apache.org/jira/browse/SOLR-11892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
>
> In privateDeleteFile, just use deleteIfExists.
> in RamDirectory we can declare a static exception and create it once.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
