[
https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664507#comment-16664507
]
ASF GitHub Bot commented on CXF-7883:
-------------------------------------
ffang closed pull request #466: [CXF-7883] fix: handle connectionRequestTimeout
in AsyncHTTPConduitFactory
URL: https://github.com/apache/cxf/pull/466
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
b/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
index d616dda5fce..15445bc33db 100644
---
a/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
+++
b/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
@@ -375,11 +375,9 @@ public void addCookie(Cookie cookie) {
client = httpAsyncClientBuilder.build();
// Start the client thread
client.start();
- if (this.connectionTTL == 0) {
- //if the connection does not have an expiry deadline
- //use the ConnectionMaxIdle to close the idle connection
- new CloseIdleConnectionThread(connectionManager, client).start();
- }
+ //Always start the idle checker thread to validate pending requests and
+ //use the ConnectionMaxIdle to close the idle connection
+ new CloseIdleConnectionThread(connectionManager, client).start();
}
//provide a hook to customize the builder
@@ -401,20 +399,28 @@ public CloseableHttpAsyncClient createClient(final
AsyncHTTPConduit c) throws IO
public CloseIdleConnectionThread(PoolingNHttpClientConnectionManager
connMgr,
CloseableHttpAsyncClient client) {
- super();
+ super("CXFCloseIdleConnectionThread");
this.connMgr = connMgr;
this.client = client;
}
@Override
public void run() {
+ long nextIdleCheck = System.currentTimeMillis() +
connectionMaxIdle;
try {
while (client.isRunning()) {
synchronized (this) {
- sleep(connectionMaxIdle);
- // close connections
- // that have been idle longer than specified
connectionMaxIdle
- connMgr.closeIdleConnections(connectionMaxIdle,
TimeUnit.MILLISECONDS);
+ sleep(selectInterval);
+ // make sure pending leases fail in a timely manner,
+ // not just when a connection becomes available
+ connMgr.validatePendingRequests();
+
+ if (connectionMaxIdle > 0 &&
System.currentTimeMillis() >= nextIdleCheck) {
+ nextIdleCheck += connectionMaxIdle;
+ // close connections
+ // that have been idle longer than specified
connectionMaxIdle
+ connMgr.closeIdleConnections(connectionMaxIdle,
TimeUnit.MILLISECONDS);
+ }
}
}
} catch (InterruptedException ex) {
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Handle connectionRequestTimeout in AsyncHTTPConduitFactory
> ----------------------------------------------------------
>
> Key: CXF-7883
> URL: https://issues.apache.org/jira/browse/CXF-7883
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.2.6
> Reporter: Györgyey Tamás
> Assignee: Freeman Fang
> Priority: Major
> Labels: pull-request-available
>
> This issue is a follow-up to CXF-7878.
> If connections are contended towards a slow target, it may make sense
> to set connectionTimeout and connectionRequestTimeout to values much lower
> than
> the receiveTimeout. Expected client behavior is to receive an error if a
> connection
> does not become available within connectionRequestTimeout. Current behavior
> however
> is that the error is only received after up to receiveTimeout has passed,
> when a
> current request to the target has finished and the connection is released or
> returned
> to the pool.
> This causes a possible build-up of pending requests in memory for the
> duration of receiveTimeout instead of connectionRequestTimeout.
> See github PR: [https://github.com/apache/cxf/pull/466]
> The reference solution in the PR works well, but it may not be the most
> elegant one due to my currently limited understanding of the overall design
> of the connection handling code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
