[
https://issues.apache.org/jira/browse/SOLR-12386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488143#comment-16488143
]
Uwe Schindler commented on SOLR-12386:
--------------------------------------
bq. And now that i look at it again: if we used Enumeration<URL>
getResources(String name) instead of URL getResource(String) wouldn't that
ensure we would get an IOException instead of "null" in the case you're talking
about where even the lookup of the name failed because of too many filehandles?
This could work if we create a static utility method taking Class or
ClassLoader and a resource name, returning an InputStream. Unfortunately there
is no Class#getResources(), it's only on classloader. We still have the problem
outside of Solr's code that after running out of file handles, loading of
resources fails - and sometimes fails with NPE!
IMHO, the file handle leak in the mentioned commit could habe been fixed by
just using try-with-resources around Class(Loader)#getResourceAsStream(). But
we should fix the underlying issue (the leaks first), then think about
improving that situation.
> Test fails for "Can't find resource" for files in the _default configset
> ------------------------------------------------------------------------
>
> Key: SOLR-12386
> URL: https://issues.apache.org/jira/browse/SOLR-12386
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Minor
> Attachments: cant find resource, stacktrace.txt
>
>
> Some tests, especially ConcurrentCreateRoutedAliasTest, have failed
> sporadically failed with the message "Can't find resource" pertaining to a
> file that is in the default ConfigSet yet mysteriously can't be found. This
> happens when a collection is being created that ultimately fails for this
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
