[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Györgyey Tamás updated CXF-7883: -------------------------------- Description: 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] was: 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 > 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 > 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] -- This message was sent by Atlassian JIRA (v7.6.3#76005)