Hi Dan, > However, we like to have > some sort of timeout so your "main thread" doesn't hang indefinitely which > could happen if the service goes down while processing or similar. Thus, the > timeout shown above on the ClientImpl.
Would be more usable here to set default timeout to infinite and provide possibility to customize the value? Regards, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Montag, 17. März 2014 20:54 > To: [email protected]; Guzmán Llambías > Subject: Re: http-conduit timeout for long delay decoupled responses > > > You'll likely need to do: > > ((ClientImpl)ClientProxy.getClient(proxy)).setSynchronousTimeout(180000); > > or similar. Unfortunately, there isn't any other way to configure this. > :-( > > That said, I'd recommend a different approach.. > > There are a few different "types" of timeouts that may apply in different > scenarios. The main one you normally would use is the conduit level receive > time out - this is the one set on the conduit and would be used for purely > synchronous transport level IO. Basically, after a request is sent, how > long to > wait on the actually connection for a response. This works fine for normal > synchronous calls as you send the request and you want right on that > HTTPUrlConnection for the response. However, when using decoupled > responses, that timeout doesn't work very well for what you need. We send the > request and then wait on the HTTPUrlConnection like normal, the server sends > back the 202 partial response to "accept" the request, and we're then done > with the connection. As long as the 202 came back in a timely manner, we > wouldn't hit the receive timeout at the connection level. > > That's where the above timeout occurs. If you are calling a synchronous > method (response expected) using a decoupled response, the ClientImpl then > has to wait for the response to come in. We support having the response come > in on a different transport than what was used to send the request so a > transport level timeout wouldn't be appropriate. However, we like to have > some sort of timeout so your "main thread" doesn't hang indefinitely which > could happen if the service goes down while processing or similar. Thus, the > timeout shown above on the ClientImpl. And yes, I DO think there should be a > better way to configure that. > > HOWEVER, I would STONGLY suggest that you flip to generating the async > methods (-asyncMethod flag to wsdl2java) and use those for this case. In > that > case, you would use one of the two async style methods that pass a callback or > provide a Future that you can use. Since the client wouldn't have to wait > for > anything, no timeouts would occur and you can "control" that aspect yourself > with the appropriate wait calls. Also, you main thread can go on and do > other > things if you can handle it that way. > > > Dan > > > > > On Mar 17, 2014, at 3:19 PM, Guzmán Llambías > <[email protected]> wrote: > > > Hi Andrei! > > > > I monitor the exchanged messages and the service receives the request > > and correctly sends the answer to the decoupled-endpoint > > (http-conduit). When the service processing delays more than 60segs, a > > timeout occurs on the client. I attach the Client Project > > > > regards > > Guzmán > > > > -----Mensaje original----- From: Andrei Shakirin > > Sent: Saturday, March 15, 2014 9:15 AM > > To: [email protected] > > Subject: RE: http-conduit timeout for long delay decoupled responses > > > > Hi, > > > > For decoupled responses timeout should not be relevant - response will be > sent using separate HTTP channel. > > You are sure that request arrives the service and service sends the > > response? > > Try to configure TCP monitor to catch network communication and see what > happens. > > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Guzmán Llambías [mailto:[email protected]] > >> Sent: Freitag, 14. März 2014 15:59 > >> To: [email protected] > >> Subject: http-conduit timeout for long delay decoupled responses > >> > >> Hi guys! > >> > >> I tried using the http-conduit and worked fine but when the service > >> has a long delay to send the answer, a timeout error occurs. I tried > >> to use the receiveTimeout attribute but it didn't work. Could you > >> please tell me how to config this timeout? > >> > >> Here's my cxf.xml configuration: > >> > >> <http:conduit > >> > name="{http://abitab.com.uy/servicios/addressing}AddressingSampleImplPort. > >> http-conduit"> > >> <http:client > >> DecoupledEndpoint="http://localhost:28080/AddressingEndpoint/Addressi > >> ngEnd > >> pointServlet" > >> ReceiveTimeout="300000" /> > >> </http:conduit> > >> > >> And here's my client code: > >> URL wsdlURL = new > >> > URL("http://localhost:8080/AbitabWSSamples/AddressingSampleImpl?wsdl";); > >> AddressingSampleImplService service = new > >> AddressingSampleImplService(wsdlURL); > >> AddressingSample port = service.getAddressingSampleImplPort(); > >> int result = port.add(1, 2); > >> System.out.println(result); > >> > >> the service publishes the ws-addressing policy, that's why I only > >> config the http- conduit > >> > >> here's the log: > >> INFO: Loaded configuration file cxf.xml. > >> 14/03/2014 11:51:30 AM > >> org.apache.cxf.service.factory.ReflectionServiceFactoryBean > >> buildServiceFromWSDL > >> INFO: Creating Service > >> {http://abitab.com.uy/servicios/addressing}AddressingSampleImplServic > >> e from > >> WSDL: http://localhost:8080/AbitabWSSamples/AddressingSampleImpl?wsdl > >> 14/03/2014 11:51:30 AM org.apache.cxf.transport.http.HTTPConduit > >> setUpDecoupledDestination > >> INFO: creating decoupled endpoint: > >> http://localhost:28080/AddressingEndpoint/AddressingEndpointServlet > >> 14/03/2014 11:52:30 AM org.apache.cxf.endpoint.ClientImpl > >> waitResponse > >> ADVERTENCIA: Timed out waiting for response to operation > >> {http://addressing.test/}add. > >> Exception in thread "main" java.lang.NullPointerException > >> at com.sun.proxy.$Proxy40.add(Unknown Source) > >> at > >> test.addressing.cxf.clientsample.AddressingCXFClientSample.main(Addre > >> ssingC > >> XFClientSample.java:46) > >> > >> thanks in advance > >> Regards > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
