You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Roger Lehmann (Jira)" <ji...@apache.org> on 2020/05/05 08:21:00 UTC
[jira] [Commented] (SOLR-14457) SolrClient leaks connections on
compressed responses if the response is malformed
[ https://issues.apache.org/jira/browse/SOLR-14457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099650#comment-17099650 ]
Roger Lehmann commented on SOLR-14457:
--------------------------------------
I can confirm this issue happening even with Solr 8.5.0 and standalone mode.
Also I came to the same conclusion, the exception is fired but handled silently, i.e. simply skipped.
Properly closing the connection even when the exception occurs is the preferred solution form my point of view.
> SolrClient leaks connections on compressed responses if the response is malformed
> ---------------------------------------------------------------------------------
>
> Key: SOLR-14457
> URL: https://issues.apache.org/jira/browse/SOLR-14457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Affects Versions: 7.7.2
> Environment: Solr version: 7.7.2
> Solr cloud enabled
> Cluster topology: 6 nodes, 1 single collection, 10 shards and 3 replicas. 1 HTTP LB using
> Round Robin over all nodes
> All cluster nodes have gzip enabled for all paths, all HTTP verbs and all MIME types.
> Solr client: HttpSolrClient targeting the HTTP LB
> Reporter: Samuel García Martínez
> Priority: Major
>
> h3. Summary
> When the SolrJ receives a malformed response Entity, for example like the one described in SOLR-14456, the client leaks the connection forever as it's never released back to the pool.
> h3. Problem description
> HttpSolrClient should have compression enabled, so it uses the compression interceptors.
> When the request is marked with "Content-Encoding: gzip" but for whatever reason the response is not in GZIP format, when HttpSolrClient tries to close the connection using Utils.consumeFully(), it tries to create the GzipInputStream failing and throwing an Exception. The exception thrown makes it impossible to access the underlying InputStream to be closed, therefore the connection is leaked.
> Despite that the content in the response should honour the headers specified for it, SolrJ should be reliable enough to prevent the connection leak when this scenario happens. On top of the bug itself, not being able to set a timeout while waiting for a connection to be available, makes any application unresponsive as it will run out of threads eventually.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org