[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615094#comment-15615094
]
Freeman Fang commented on CXF-6910:
-----------------------------------
Hi Sebastien,
What I mentioned
{code}
if there's no data on the socket in a certain time, the connection would be
closed
{code}
may be need rephrase as
{code}
RequestConfig.setSocketTimeout
the time waiting for data – after the connection was established; maximum time
of inactivity between two data packets
{code}
So think about this scenario
you client have a connection already which has SocketTimeout as 15sec but TTL
as 30 sec
client.invoke1();// return immediately
Thread.sleep(20000)//sleep 20 sec
client.invoke2();//return immediately
So here invoke1 and invoke2 will use two different connection(because sleep 20
sec cause inactivity between two data packets on first connection
SocketTimeout), but not reuse the connection TTL.
So here the SocketTimeout doesn't mean the "ReceiveTimeout" for one invocation,
it's just the "maximum time of inactivity between two data packets", that's why
we can't use RequestConfig.setSocketTimeout as "ReceiveTimeout" for a
HttpConduit.
Hope this can clarify.
Best Regards
Freeman
> 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)
