[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614782#comment-15614782
]
Sebastien Petrucci commented on CXF-6910:
-----------------------------------------
Hello Fang,
While trying to understand the root cause of the ENTESB-6222, I read again the
story behing this improvement. And I'm a little bit confused about the reason
of this change.
You mention "[...] if there's no data on the socket in a certain time, the
connection would be closed, this overrule the TTL value of a connection [...]".
In fact, I would *expect* the connection to be closed before the TTL in case of
timeout. Because if the timeout occurs then it means that the response was not
received and that there is no certainty on the state of that connection. As
such, it cannot be put back into the connection pool and should be closed right
away. Connection TTL should only apply to unactive connections on which all
requests where successfull, which should be the case 99% of the time.
Do that make sense ?
Best Regards,
Sebastien.
> don't need setSocketTimeout when create ahc RequestConfig
> ---------------------------------------------------------
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Reporter: Freeman Fang
> Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
