[
https://issues.apache.org/jira/browse/SOLR-14457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel García Martínez updated SOLR-14457:
------------------------------------------
Description:
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.
was:
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.
If Solr (for whatever reason) or any intermediate networking piece (firewall,
proxy, load balancer) messes up the response, SolrJ tries to release the
connection but GzipDecompressingEntity#getContent fails with an
IOException("Not in GZIP format"), making it impossible to release the
connection.
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.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
