[
https://issues.apache.org/jira/browse/SOLR-14457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408395#comment-17408395
]
Houston Putman commented on SOLR-14457:
---------------------------------------
[~samuelgmartinez] & [~roger.lehmann] I have a patch up that should fix this.
Let me know what y'all think and/or if it works for you when you test it out.
> 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
> 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
> Attachments: content-gzipped.png, multiple-wrapped-entities.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
