[
https://issues.apache.org/jira/browse/SOLR-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793721#comment-13793721
]
Oleg Kalnichevski commented on SOLR-4327:
-----------------------------------------
This is none of my business, but I think and catching and ignoring Throwables
is an _exceptionally_ bad idea
{code}
try {
respBody.close();
} catch (Throwable t) {} // ignore
{code}
At the very least it should be
{code}
try {
respBody.close();
} catch (Exception ignore) {}
{code}
> SolrJ code review indicates potential for leaked HttpClient connections
> -----------------------------------------------------------------------
>
> Key: SOLR-4327
> URL: https://issues.apache.org/jira/browse/SOLR-4327
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Karl Wright
> Assignee: Mark Miller
> Fix For: 4.5.1, 4.6, 5.0
>
> Attachments: SOLR-4327.patch, SOLR-4327.patch
>
>
> The SolrJ HttpSolrServer implementation does not seem to handle errors
> properly and seems capable of leaking HttpClient connections. See the
> request() method in org.apache.solr.client.solrj.impl.HttpSolrServer. The
> issue is that exceptions thrown from within this method do not necessarily
> consume the stream when an exception is thrown. There is a try/finally block
> which reads (in part):
> {code}
> } finally {
> if (respBody != null && processor!=null) {
> try {
> respBody.close();
> } catch (Throwable t) {} // ignore
> }
> }
> {code}
> But, in order to always guarantee consumption of the stream, it should
> include:
> {code}
> method.abort();
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
