You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Alain PANNETIER <al...@gmail.com> on 2010/07/07 01:02:47 UTC
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
way similar to this :
private static final QName SERVICE_NAME = new QName("
http://my.service.com/", "MyService");
private static MyService port ;
private HTTPConduit conduit ;
private HTTPClientPolicy policy ;
(...)
URL wsdlURL = MyService.WSDL_LOCATION;
MyService ss = new MyService(wsdlURL, SERVICE_NAME);
port = ss.getMyServicesSoap();
// Get client
Client client = ClientProxy.getClient( port );
// Set response overall timeout to 5 minutes
((ClientImpl) client ).setSynchronousTimeout( 5 * 60 * 1000);
// Set Connection and socket timeout to 2 minutes
conduit = (HTTPConduit)client.getConduit();
policy = conduit.getClient();
policy.setConnectionTimeout ( 120000 );
policy.setReceiveTimeout( 12000 ) ;
(...)
Where MyService and MyServiceSoap are classes generated by jaxws wsdl2java
(e.g. from CXF).
Does that fit your requirements ?
Alain Pannetier
On Tue, Jul 6, 2010 at 11:30 PM, KARR, DAVID (ATTSI) <dk...@att.com> 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.
>
Re: Can CXF easily support an "absolute" read timeout on a service
call?
Posted by Alain PANNETIER <al...@gmail.com>.
To be honest, I don't know about the synchronous timeout..
Because the socket timeout (read: read timeout) always aborted my call
before (default is 60secs).
So I'm positive this *socket* timeout interrupts the call in an average of
10ms after it's expired.
Alain
On Wed, Jul 7, 2010 at 12:19 AM, KARR, DAVID (ATTSI) <dk...@att.com> wrote:
> > -----Original Message-----
> > From: Alain PANNETIER [mailto:alain.pannetier@gmail.com]
> > Sent: Tuesday, July 06, 2010 4:03 PM
> > To: users@cxf.apache.org
> > 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) <dk...@att.com>
> > 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.
> > >
>
Re: Can CXF easily support an "absolute" read timeout on a service call?
Posted by Daniel Kulp <dk...@apache.org>.
the synchronous timeout would not apply for http. It's really just used for
the transports that, by nature, are not synchronous themselves and thus need
to wait on the main thread for the response to come in elsewhere. The
original JMS transport was this way (current one is not) and the Local
transport uses this in some cases.
Dan
On Tuesday 06 July 2010 7:19:09 pm KARR, DAVID (ATTSI) wrote:
> > -----Original Message-----
> > From: Alain PANNETIER [mailto:alain.pannetier@gmail.com]
> > Sent: Tuesday, July 06, 2010 4:03 PM
> > To: users@cxf.apache.org
> > 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) <dk...@att.com>
> >
> > 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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
RE: Can CXF easily support an "absolute" read timeout on a service call?
Posted by "KARR, DAVID (ATTSI)" <dk...@att.com>.
> -----Original Message-----
> From: Alain PANNETIER [mailto:alain.pannetier@gmail.com]
> Sent: Tuesday, July 06, 2010 4:03 PM
> To: users@cxf.apache.org
> 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) <dk...@att.com>
> 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.
> >