You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2016/10/28 10:59:58 UTC

[jira] [Comment Edited] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig

    [ https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615094#comment-15615094 ] 

Freeman Fang edited comment on CXF-6910 at 10/28/16 10:59 AM:
--------------------------------------------------------------

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 was overruled)
So here the SocketTimeout doesn't mean the "ReceiveTimeout" for one long invocation waiting for response, 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


was (Author: ffang):
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)