cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
Date Fri, 28 Oct 2016 10:56:59 GMT

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

Mime
View raw message