> -----Original Message----- > From: Alain PANNETIER [mailto:[email protected]] > Sent: Tuesday, July 06, 2010 4:03 PM > To: [email protected] > Subject: Re: Can CXF easily support an "absolute" read timeout on a > service call? > > Hi David, > > For SOAP, a standard CXF client uses a CXF class named HTTPConduit, > which internally uses the java.net.HttpURLConnection class. > > For the latter, a JSE class then, you can set 2 timeouts, > - the socket connect timeout > - the socket read timeout (since 1.5) > > CXF's HTTPConduit allows clients to set these values through so-called > policies > for which there are (resp) two getters/setters: > get/setConnectionTimeout > get/setReceiveTimeout > > In addition there is an "overall timeout" called Synchronous Timeout. > You can all change these values whenever you want (i.e. between calls) > in a > [deleted] > > Does that fit your requirements ?
I can't find this in the CXF documentation, either in the doc or the javadoc. Is this "synchronous timeout" really going to kill the connection with prejudice from the client side if the timeout expires, no matter what the server-side is doing? > On Tue, Jul 6, 2010 at 11:30 PM, KARR, DAVID (ATTSI) <[email protected]> > wrote: > > > I work with some middleware that makes SOAP calls with an ad hoc > > internal framework using HttpClient 3.0.1. We set the "socket > timeout" > > on HttpClient, but we were really intending that to be an absolute > > timeout on the web service call. The socket timeout is really only > used > > "per packet" so it's very easy for absolute times on service calls to > be > > well over the "read timeout" value. > > > > As I don't think I can fix this with HttpClient out of the box, I'm > > investigating the possibility of having a background task kill > > connections if they've gone past their time limit. > > > > What I'd like to ask here, though, is whether CXF has any direct or > > indirect support for solving this problem. I've been considering > > putting CXF in here instead of the ad hoc framework combined with raw > > HttpClient, but I'm looking for specific points to support this. If > I > > could more easily support this "absolute time out" feature, that > would > > be a plus. > >
