[
https://issues.apache.org/jira/browse/HTTPCLIENT-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172236#comment-17172236
]
Oleg Kalnichevski commented on HTTPCLIENT-2039:
-----------------------------------------------
bq. It's kinda normal case for a OOM to occur in our processing logic and we
will handle that according and recover.
Are you sure or kinda sure? It is not even clear whether standard Java
collection classes can recover from OOM.
bq. Is it possible to control this breaking change via a configuration?
[~seanguo]Â Subclass {{PoolingHttpClientConnectionManager}}, override and
disable its {{#shutdown}} method, provide a custom shutdown routine that calls
{{super#shutdown}}. At your own peril.
Oleg
> Do not close ConnectionManager in case of Errors
> ------------------------------------------------
>
> Key: HTTPCLIENT-2039
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2039
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.10
> Reporter: Thomas Sartissohn
> Priority: Minor
>
> The MainClientExec closes the connectionManager in the execute method
> whenever a java error is received. In my case an OutOfMemoryError was thrown.
> This ended in a client instance no longer usable cause the pool was already
> shut down. And therefore the real error (OutOfMemoryError) was covered by
> many "Connection pool shut down" exceptions.
> I agree that the OutOfMemoryError is a severe issue which should be covered
> somehow. But closing the pool is unexpected here.
> Is there a chance to remove the closing part and keep the pool running in
> error case?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
