Hi Manuel,
AFAIK CXF does not use
org.springframework.core.io.AbstractFileResolvingResource (at least, directly).
Could you please trace where the last resource fetching attempt is coming from?
Thank you.
Best Regards,
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
