[ https://issues.apache.org/jira/browse/SOLR-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Drob updated SOLR-8933: ---------------------------- Attachment: SOLR-8933.patch bq. The ContentStream tests are using remote streams (actually a file:// URL for testing). So on Windows, tests should fail with a resource leak there. The cases in {{ContentStreamTest}} are still closing everything. I don't understand what the relation there is. I haven't tested with Windows though, so maybe there is additional nuance I am missing. I found the part where we are processing remote stream parameter to set the content stream... Maybe it makes sense to make ContentStream implement Closeable and then we can know to close the URL and File streams but not the Servlet, Byte, or String streams. They're all build from the Request in {{SolrRequestParsers::parse}} - at which point we can make that determination. The next question becomes then, who is responsible for closing the ContentStream? It's easy to make the SolrRequest responsible for the ContentStreams it creates, but I am not sure if there are other cases. And there are too many warnings in the project for me to reliably tell what I'm missing. Here's a proposed patch heading down this path, likely incomplete. > SolrDispatchFilter::consumeInput logs "Stream Closed" IOException > ----------------------------------------------------------------- > > Key: SOLR-8933 > URL: https://issues.apache.org/jira/browse/SOLR-8933 > Project: Solr > Issue Type: Bug > Affects Versions: 4.10.3 > Reporter: Mike Drob > Assignee: Mark Miller > Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, > SOLR-8933.patch, SOLR-8933.patch > > > After SOLR-8453 we started seeing some IOExceptions coming out of > SolrDispatchFilter with "Stream Closed" messages. > It looks like we are indeed closing the request stream in several places when > we really need to be letting the web container handle their life cycle. I've > got a preliminary patch ready and am working on testing it to make sure there > are no regressions. > A very strange piece of this is that I have been entirely unable to reproduce > it on a unit test, but have seen it on cluster deployment quite consistently. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org