TCP KeepAlives

[Jim Talbut <jt...@spudsoft.co.uk>]

Hi,

Is there any way to get TCP KeepAlives (NOT HTTP KeepAlives) enabled for 
a CXF client?

I have a client making a request to a server that is taking a very long 
time respond, and in that time the firewall in between is closing the 
connection due to inactivity.

Thanks.

Jim

Re: TCP KeepAlives

[Daniel Kulp <dk...@apache.org>]

On Mar 27, 2013, at 4:15 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:

> On 27/03/2013 19:22, Daniel Kulp wrote:
>> On Mar 27, 2013, at 3:02 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
>>> Hi,
>>> Is there any way to get TCP KeepAlives (NOT HTTP KeepAlives) enabled for a CXF client?
>> 
>> The normal HTTPConduit that we use is based on the in-JDK HttpURLConnection object.
> >
>> You may have better luck with the Apache HTTP Async Client based HTTPConduit:
>> http://cxf.apache.org/docs/asynchronous-client-http-transport.html
>> there are settings already there for setting the SO_KEEPALIVE and such.
> Being asynchronous wouldn't actually help my client at all (I need to hog the thread or other things will go wrong at my end),
> but looking at it am I right in thinking that with just a bit of pom and spring work I can change to use the async client synchronously,
> getting me keep-alives without any code changes?
> And does that apply even though my clients are created in code (service class constructor followed by adding the port and tweaking the BindingProvider and HttpClientPolicy)?

Well, adding the -hc jar to the classpath would use the hc stuff for async calls by default.   However, for the sync calls to also use the hc transport would require you to set a property.     That could be done in code or via spring config or whatever.    That really would be the only change needed. 

Dan



>>> I have a client making a request to a server that is taking a very long time respond, and in that time the firewall in between is closing the connection due to inactivity.
>> 
>> If you have control over the server, you could have it send back periodic HTTP 100 Continue things to keep some activity on the connection.
> It's a .Net web service, I'm not sure I have that much control over it.
> 
>> That said, if it's normal to take that long, it's likely better to split the request into two parts:
> My client calls lots of different services, some take a long time, some are quick.
> I suppose I could split them into two sets and handle them differently - I'll look into that.
> 
> Thanks.
> 
> Jim

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: TCP KeepAlives

[Jim Talbut <jt...@spudsoft.co.uk>]

On 27/03/2013 19:22, Daniel Kulp wrote:
> On Mar 27, 2013, at 3:02 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
>> Hi,
>> Is there any way to get TCP KeepAlives (NOT HTTP KeepAlives) enabled for a CXF client?
>
> The normal HTTPConduit that we use is based on the in-JDK HttpURLConnection object.
 >
> You may have better luck with the Apache HTTP Async Client based HTTPConduit:
> http://cxf.apache.org/docs/asynchronous-client-http-transport.html
> there are settings already there for setting the SO_KEEPALIVE and such.
Being asynchronous wouldn't actually help my client at all (I need to 
hog the thread or other things will go wrong at my end),
but looking at it am I right in thinking that with just a bit of pom and 
spring work I can change to use the async client synchronously,
getting me keep-alives without any code changes?
And does that apply even though my clients are created in code (service 
class constructor followed by adding the port and tweaking the 
BindingProvider and HttpClientPolicy)?

>> I have a client making a request to a server that is taking a very long time respond, and in that time the firewall in between is closing the connection due to inactivity.
>
> If you have control over the server, you could have it send back periodic HTTP 100 Continue things to keep some activity on the connection.
It's a .Net web service, I'm not sure I have that much control over it.

> That said, if it's normal to take that long, it's likely better to split the request into two parts:
My client calls lots of different services, some take a long time, some 
are quick.
I suppose I could split them into two sets and handle them differently - 
I'll look into that.

Thanks.

Jim

Re: TCP KeepAlives

[Daniel Kulp <dk...@apache.org>]

On Mar 27, 2013, at 3:02 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:

> Hi,
> 
> Is there any way to get TCP KeepAlives (NOT HTTP KeepAlives) enabled for a CXF client?

The normal HTTPConduit that we use is based on the in-JDK HttpURLConnection object.   Looking through there (and some googling) and I'm not seeing any way at all to control the SO_KEEPALIVE of the underlying socket.   There is no access to the Socket at all.    You MAY be able to use some reflection or something to get to the private fields of the underlying Oracle implementation to set it, but that certainly won't be easy.

You may have better luck with the Apache HTTP Async Client based HTTPConduit:
http://cxf.apache.org/docs/asynchronous-client-http-transport.html
there are settings already there for setting the SO_KEEPALIVE and such.

> I have a client making a request to a server that is taking a very long time respond, and in that time the firewall in between is closing the connection due to inactivity.

If you have control over the server, you could have it send back periodic HTTP 100 Continue things to keep some activity on the connection.    That said, if it's normal to take that long, it's likely better to split the request into two parts:

String doSomethingThatMayTakeAWhile(…params);
Result getResult(String…);

Return immediately from the first with some sort of ID or something.   Then on the client side, immediately call the second which can block waiting for the result.    If the second call times out or connection is dropped, just call it again.


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com