Hoss Man created SOLR-12021:

             Summary: Utils.fromJSONResource(...) and 
ValidatingJsonMap.parse(...) open (resourse) InputStreams they don't close
                 Key: SOLR-12021
                 URL: https://issues.apache.org/jira/browse/SOLR-12021
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Hoss Man
            Assignee: Hoss Man

A recurring theme that pops up now and then in non-reproducible test failures 
is for an error like this to show up in the log files when a core/collection is 
being created...

   [junit4]   2> 674805 ERROR (qtp1337497394-5597) [n: 
c:collection2 s:shard6  x:collection2_shard6_replica_n29] 
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error 
CREATEing SolrCore 'collection2_shard6_replica_n29': Unable to create core 
[collection2_shard6_replica_n29] Caused by: invalid API spec: 
   [junit4]   2> Caused by: java.lang.RuntimeException: invalid API spec: 
   [junit4]   2>        at 
   [junit4]   2>        at 
   [junit4]   2>        at org.apache.solr.api.Api.getSpec(Api.java:65)
   [junit4]   2>        at org.apache.solr.api.ApiBag.register(ApiBag.java:73)
   [junit4]   2>        at 
   [junit4]   2>        at 
   [junit4]   2>        at 
   [junit4]   2>        at 

I _believe_ that the root cause of these types of failures is that these API 
spec files are being loaded with 
-- but nothing is ever closing the stream, so it can eventually (depending on 
what test classes run in each JVM and how many files they try to open like 
this) cause the JVM to hit the ulimit for open file handles -- but that 
specific cause of the failure is never reported, because 
{{ClassLoader.getResourseAsStream(...)}} is explicity designed to swallow any 
IOExceptions encountered and just returns "null" (which triggers the "invalid 
API spec: " thrown by ValidatingJsonMap)


{{ValidatingJsonMap.parse(...)}} and the very similarly looking 
{{Utils.fromJSONResource(...)}} should be modified to:
* ensure they always close the streams they open
* use {{ClassLoader.getResource()}} + {{URL.openConnection()}} so that they can 
properly log if/when an underlying IOException occurs w/details

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to