[
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: [email protected]
For additional commands, e-mail: [email protected]
