[ https://issues.apache.org/jira/browse/SOLR-15717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435404#comment-17435404 ]
Jan Høydahl commented on SOLR-15717: ------------------------------------ Thinking some more, this isn't really a leak, it is just that JVM may use a little longer time to dispose of the stream resources if we don't close the stream explicitly. And given that none of the code paths are frequently-used, this is a theoretical problem, and a change poses a bigger risk than the issue it attempts to fix. Also, when it comes to the two locations in SolrCLI.java, those are dead code which is better removed than patched. I have opened SOLR-15728 for this. I propose to close this as "Won't do". Any comments from other committers? This is not to say we don't appreciate the contribution :) > Fix resource leak due to Files.find > ----------------------------------- > > Key: SOLR-15717 > URL: https://issues.apache.org/jira/browse/SOLR-15717 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: lujie > Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Files.walk and Files.find will open stream and as jdk said: > > * If timely disposal of file system resources is required, the > * \{@code try}-with-resources construct should be used to ensure that the > * stream's \{@link Stream#close close} method is invoked after the stream > * operations are completed. > we sould close them with try catch > > patch is ready! see > > https://github.com/apache/solr/pull/368 -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org