You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2018/05/23 22:47:00 UTC
[jira] [Comment Edited] (SOLR-12386) Test fails for "Can't find
resource" for files in the _default configset
[ https://issues.apache.org/jira/browse/SOLR-12386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488143#comment-16488143 ]
Uwe Schindler edited comment on SOLR-12386 at 5/23/18 10:46 PM:
----------------------------------------------------------------
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 (depending on the brokenness of code)!
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.
was (Author: thetaphi):
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org