[
https://issues.apache.org/jira/browse/SOLR-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353445#comment-15353445
]
Gary Lee commented on SOLR-9248:
--------------------------------
Hi Mike, yes this did work in 5.4. I tested it before on 5.4 and the logic was
to close the response input stream directly (respBody.close()) instead of
calling EntityUtils.consumeFully, so the GZIPInputStream was getting closed
properly and we weren't losing connections.
The stack trace is based on 5.5, so doesn't directly correspond with 5.5.2 -
sorry if that led to any confusion. But your explanation is correct and that is
exactly the problem I see. The exception is now ignored (which is why it's not
straightforward to get a stack trace in the logs anymore), but the end result
is that the respBody input stream is never closed. I believe respBody is the
GZIPInputStream that needs to be closed, because I'm seeing that the connection
continues to stay leased and eventually the httpClient doesn't accept new
connections anymore.
Your comment on "The GZIPInputStream from the GzipDecompressingEntity was never
fully constructed" is true when calling EntityUtils.consumeFully, but the
GZIPInputStream is first constructed at the time we need to read the response,
and that completes without a problem. It's the next time that we try to do the
same thing where the error occurs, and the initial GZIPInputStream (respBody)
never gets closed. Since the GZipDecompressingEntity is providing a new stream
every time, it essentially ignores the one was previously constructed, and thus
never achieves the purpose of closing out an input stream.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
