You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Shenavai, Manuel" <ma...@sap.com.INVALID> on 2021/08/13 13:03:59 UTC
External WSDLS and connection/read timeouts
Hi everyone,
we are using Camel CXF and found the following problem:
It can happen that a route is trying to start for an infinite amount of time due to missing response from WSDL endpoint.
Setup:
A CXF endpoint that is using an external WSDL (i.e. wsdlURL=http://someHost/test/wsdl)
The WSDL endpoint is not responding
A conduit configured with 100ms timeouts (connections- and read-timeout)
Test:
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
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.
I did some debugging and found several requests are done for the WSDL with different timeouts (in this order):
1. org.apache.cxf.transport.http.URLConnectionHTTPConduit:134
* connectionTimeout 100 ms
* readTimeout 100 ms
* timeout-values are taken from conduit
1. org.apache.cxf.resource.URIResolver:282
* connectionTimeout 30 seconds
* readTimeout 60 seconds
* hardcoded values
1. org.springframework.core.io.AbstractFileResolvingResource:60
* connectionTimeout 0 //infinite waiting
* readTimeout 0 //infinite waiting
* no explicit timeouts are set
Our main problem here is the last request that has no timeout configured at all. I attached the stacktrace of the blocked thread.
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?
Thanks in advance
Best regards,
Manuel
RE: External WSDLS and connection/read timeouts
Posted by "Shenavai, Manuel" <ma...@sap.com.INVALID>.
Hi Andriy,
I tested the suggested system properties and I can confirm that they are working. Thanks for your help!
Best regards,
Manuel
-----Original Message-----
From: Andriy Redko <dr...@gmail.com>
Sent: Mittwoch, 18. August 2021 03:58
To: Shenavai, Manuel <ma...@sap.com>; dev@cxf.apache.org
Subject: Re: External WSDLS and connection/read timeouts
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 <dr...@gmail.com>
SM> Sent: Dienstag, 17. August 2021 01:46
SM> To: Shenavai, Manuel <ma...@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
Re: External WSDLS and connection/read timeouts
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@gmail.com>
SM> Sent: Dienstag, 17. August 2021 01:46
SM> To: Shenavai, Manuel <ma...@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
RE: External WSDLS and connection/read timeouts
Posted by "Shenavai, Manuel" <ma...@sap.com.INVALID>.
Hi Andriy,
thanks for your reply. I attached the stacktrace of the stuck call. This should give you the details you ask for, right?
Best regards,
Manuel
-----Original Message-----
From: Andriy Redko <dr...@gmail.com>
Sent: Dienstag, 17. August 2021 01:46
To: Shenavai, Manuel <ma...@sap.com>; dev@cxf.apache.org
Subject: Re: External WSDLS and connection/read timeouts
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
Re: External WSDLS and connection/read timeouts
Posted by Andriy Redko <dr...@gmail.com>.
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