[
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)
