On Mar 27, 2013, at 4:15 PM, Jim Talbut <[email protected]> wrote:
> On 27/03/2013 19:22, Daniel Kulp wrote: >> On Mar 27, 2013, at 3:02 PM, Jim Talbut <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
