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 <guzman.llamb...@pyxisportal.com> 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: users@cxf.apache.org > 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:guzman.llamb...@pyxisportal.com] >> Sent: Freitag, 14. März 2014 15:59 >> To: users@cxf.apache.org >> 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/AddressingEnd >> 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}AddressingSampleImplService 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(AddressingC >> XFClientSample.java:46) >> >> thanks in advance >> Regards -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
