[
https://issues.apache.org/jira/browse/SOLR-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-9248:
----------------------------
Attachment: CompressedConnectionTest.java
Ok, thanks for taking an initial look. Can you confirm that this is something
that worked in earlier versions (5.4?).
I'm trying to build a unit test to reproduce this, but having a little bit of
trouble. I think I see where things are going wrong, but haven't been able to
reproduce this in a test.
When the call to {{EntityUtils.consumeFully}} happens, the code tries to get
the stream and read the rest of the bytes from it to clear out the buffers and
make servlet containers happy. However, {{GzipDecompressingEntity}} attempts to
provide a new stream each time, wrapping the same underlying content (which has
already been exhausted at this point).
Absent a way to reproduce this, it's hard to tell if this has been fixed. Your
stack trace shows {{HttpSolrClient::executeMethod}} calling
{{org.apache.http.util.EntityUtils::consume}} directly, whereas in 5.5.2 I see
{{executeMethod}} -> {{org.apache.solr.common.util.Utils::consumeFully}} ->
{{GzipDecompressingEntity::getContent}} (this will throw the exception) ->
{{org.apache.http.util.EntityUtils::consumeQuietly}}, which will make another
attempt at {{getContent}} and ignore the exception again.
Which stream are you indicating should be closed? The {{GZIPInputStream}} from
the {{GzipDecompressingEntity}} was never fully constructed, and doesn't need
to be closed. The connection itself should be managed by the servlet container,
so we shouldn't be closing it either.
I'm attaching my in-progress unit test for this.
> HttpSolrClient not compatible with compression option
> -----------------------------------------------------
>
> Key: SOLR-9248
> URL: https://issues.apache.org/jira/browse/SOLR-9248
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 5.5, 5.5.1
> Reporter: Gary Lee
> Attachments: CompressedConnectionTest.java
>
>
> Since Solr 5.5, using the compression option
> (solrClient.setAllowCompression(true)) causes the HTTP client to quickly run
> out of connections in the connection pool. After debugging through this, we
> found that the GZIPInputStream is incompatible with changes to how the
> response input stream is closed in 5.5. It is at this point when the
> GZIPInputStream throws an EOFException, and while this is silently eaten up,
> the net effect is that the stream is never closed, leaving the connection
> open. After a number of requests, the pool is exhausted and no further
> requests can be served.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
