Hi Manuel, Thank you, it is clear now, the CXF delegates to the Spring context the resource (WSDL) loading part. So AFAIK Spring does not provide the way to propagate connect/read timeout to URL resources (at least, no easy way), you could still use JVM system properties [1] to set your own timeouts, they will be applied by default (both are milliseconds) :
sun.net.client.defaultConnectTimeout sun.net.client.defaultReadTimeout For example: -Dsun.net.client.defaultReadTimeout=30000 -Dsun.net.client.defaultConnectTimeout=20000 Hope it helps. Thank you! [1] https://docs.oracle.com/javase/6/docs/technotes/guides/net/properties.html Best Regards, Andriy Redko SM> Hi Andriy, SM> thanks for your reply. I attached the stacktrace of the stuck call. This should give you the details you ask for, right? SM> Best regards, SM> Manuel SM> -----Original Message----- SM> From: Andriy Redko <drr...@gmail.com> SM> Sent: Dienstag, 17. August 2021 01:46 SM> To: Shenavai, Manuel <manuel.shena...@sap.com>; dev@cxf.apache.org SM> Subject: Re: External WSDLS and connection/read timeouts SM> Hi Manuel, SM> AFAIK CXF does not use org.springframework.core.io.AbstractFileResolvingResource (at least, directly). SM> Could you please trace where the last resource fetching attempt is coming from? SM> Thank you. SM> Best Regards, SM> Andriy Redko SM>> Hi everyone, SM>> we are using Camel CXF and found the following problem: SM>> It can happen that a route is trying to start for an infinite amount of time due to missing response from WSDL endpoint. SM>> Setup: SM>> A CXF endpoint that is using an external WSDL (i.e. wsdlURL=http://someHost/test/wsdl) SM>> The WSDL endpoint is not responding SM>> A conduit configured with 100ms timeouts (connections- and read-timeout) SM>> Test: SM>> I attached a sample app to this mail. To start the application, start DemoApplication.java. It will start a camel route containing a CXF endpoint. The CXF endpoint in the route tries to read an external WSDL. The endpoint for this WSDL is doing a 15 minute sleep before responding to simulate a "no response from WSDL endpoint" (implemented in RouteController). The conduit is configured with 100ms timeouts for connection- and readtimeout SM>> The application will fail to start if the route cannot be started. Since the WSDL can't be fetched within the 100ms timeout, I would expect the app-startup to fail at least within 1 minute. However the startup seems to go on for an infinite amount of time. SM>> I did some debugging and found several requests are done for the WSDL with different timeouts (in this order): SM>> 1. org.apache.cxf.transport.http.URLConnectionHTTPConduit:134 SM>> * connectionTimeout 100 ms SM>> * readTimeout 100 ms SM>> * timeout-values are taken from conduit SM>> 1. org.apache.cxf.resource.URIResolver:282 SM>> * connectionTimeout 30 seconds SM>> * readTimeout 60 seconds SM>> * hardcoded values SM>> 1. org.springframework.core.io.AbstractFileResolvingResource:60 SM>> * connectionTimeout 0 //infinite waiting SM>> * readTimeout 0 //infinite waiting SM>> * no explicit timeouts are set SM>> Our main problem here is the last request that has no timeout configured at all. I attached the stacktrace of the blocked thread. SM>> I would expect that the timeouts from the conduit are applied. This seems not to be the case so I think this is a bug. What do you think? SM>> Thanks in advance SM>> Best regards, SM>> Manuel
