[
https://issues.apache.org/jira/browse/HTTPCORE-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18064802#comment-18064802
]
Benjamin Peterson commented on HTTPCORE-795:
--------------------------------------------
So the http client simply does not support interruption of threads that are
inside it? Would it make sense to remove the current handling of interruption
then? Right now, it there's some handling of interruption, but it leaves open
the edge case I have described in this issue. Is there an objection to closing
that hole even if the support for interruption isn't perfect?
> interrupts and timeouts may leak connections
> --------------------------------------------
>
> Key: HTTPCORE-795
> URL: https://issues.apache.org/jira/browse/HTTPCORE-795
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Reporter: Benjamin Peterson
> Priority: Minor
> Fix For: 5.4.3, 5.5-alpha1
>
> Attachments: HttpGetExample.java, HttpGetExample2.java,
> TimeoutLeakExample.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Consider {{InternalExecRuntime.acquireEndpoint}}:
> {code:java}
> try {
> final ConnectionEndpoint connectionEndpoint =
> connRequest.get(connectionRequestTimeout);
> } catch (final TimeoutException ex) {
> connRequest.cancel();
> throw new ConnectionRequestTimeoutException(ex.getMessage());
> } catch (final InterruptedException interrupted) {
> connRequest.cancel();
> Thread.currentThread().interrupt();
> throw new RequestFailedException("Request aborted",
> interrupted);
> }
> {code}
> Consider this order of operations:
> 1. The thread blocked in {{codeRequest.get}} is interrupted or times out.
> 2. The connection pool completes the future with a connection.
> 3. The interrupted thread starts propagating the {{InterruptedException}} or
> {{TimeoutException}}. When it reaches the {{catch}} blocks, it will call
> {{connRequest.cancel()}}. But cancelation will do nothing because the
> connection pool already completed the future. The connection will leak.
> The window may be narrow, but it's certainly a possibility if heavy load
> means the blocked thread is delayed in being scheduled to propagate the
> {{InterruptedException}} or {{TimeoutException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
