Zuul ReadTimeout by Service - spring

I have a Zuul proxy, and it works fine until it redirects to a server that takes longer time than normal (more than 10 seconds) to response.
I can modify the read-timeout through properties (zuul.host.socket-timeout-millis) so it can work properly.
ribbon.eureka.enabled=false
zuul.host.connect-timeout-millis=100000
zuul.host.socket-timeout-millis=100000
But I need a different timeout based on the service that the proxy is reaching.
I don't have Eureka in my architecture so I disabled it in the properties. (ribbon.eureka.enabled=false)
I've tried with
hystrix.command.default.execution.timeout.enabled=false
hystrix.command.messages.execution.isolation.strategy=THREAD
hystrix.command.messages.execution.isolation.thread.timeoutInMilliseconds= 100000
But it doesn't work. It always use the value on zuul.host.socket-timeout-millis and if I don't set this property Zuul, uses a 10 seconds timeout.
I've also tried
messages.ribbon.ReadTimeout=120000
ribbon.ReadTimeout=60000
But it always use what is on zuul.host.socket-timeout-millis
I don't know how to set the timeout by service.
So I can set for service1 30 seconds, for service2 45 seconds and for the other services a default of 60.
How can I do this ?

I supose you have but I'll ask: Have you tried configuring both properties at the same time with a higher value?
It should work, we use this feature in Zuul and it works well but you need to configure booth timeouts (Zuul and Ribbon)
You have info about how this works here: Ribbon, Hystrix
Note that depending on how you use Zuul the name of your client could be different for Ribbon and for Hystrix.

Related

feign.RetryableException: Read timed out executing GET

I have below architecture in my project
My UI Service(Port 8080) making Feign call to Gateway Service(Port 8085).
My Get call from UI service is " http://localhost:8080/invoice-list?startDate=2018-08-05&endDate=2018-10-05 "
Similar call from Gateway Service "http://localhost:8085/invoice-download-service/invoice-list?startDate=2018-08-05&endDate=2018-10-05"
When i make this GET call from UI service i get below error within minute
is feign.RetryableException: Read timed out executing GET http://localhost:8085/invoice-download-service/invoice-list?startDate=2018-08-05&endDate=2018-10-05] with root cause
java.net.SocketTimeoutException: Read timed out
But when i make direct call from Gateway Server to microservice, i dont get error.
Application.properties file of Gateway service
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=160000000
ribbon.OkToRetryOnAllOperations=true
ribbon.ReadTimeout=5000000
ribbon.ConnectTimeout=5000000
ribbon.MaxAutoRetries=3
ribbon.MaxAutoRetriesNextServer=3
zuul.host.socket-timeout-millis= 5000000
zuul.host.connect-timeout-millis= 5000000
Here i have set readtimeout and connecttimeout property around 8 to 10 min, hence i am not getting error.
Application.properties file of UI service
spring.application.name=external-ui-service
server.port=8080
Here in UI service i dont have timeout property. I tried above properties here but not working.
Obviously this UI service is not using ribbon,zuul etc. This is just an making Feign call to gateway.
So what should i do to increase timeout in UI service?
Added below properties in UI Service's application.propeties file.
feign.client.config.default.connectTimeout: 160000000
feign.client.config.default.readTimeout: 160000000
This issue might also be caused by default laodbalancer implementation of Spring Cloud Gateway in case you make use of Eureka Server and run your microservices undockerized on windows. Services are running on localhost, but Eureka says to the loadbalancer of the gateway to route the request to host.docker.internal.
The links down below give a couple of solutions:
https://localcoder.org/spring-boot-cloud-eurka-windows-10-eurkea-returns-host-docker-internal-for-clien
https://dimitr.im/fix-eureka-localhost

Spring Cloud Eureka Server self preservation and renew threshold

(It is basically two Eureka server and three Eureka client microservices)
I want to remove the following message:
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
error image
Eureka Server1:
spring.application.name=ms-service-discovery-1
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.server.enableSelfPreservation= true
eureka.instance.leaseRenewalIntervalInSeconds=1
eviction-interval-timer-in-ms: 1000
eureka.server.wait-time-in-ms-when-sync-empty: 1000
eureka.server.responseCacheUpdateIntervalMs: 1000
Eureka Server2:
spring.application.name=ms-service-discovery-2
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.server.enableSelfPreservation= true
eureka.instance.leaseRenewalIntervalInSeconds=1
eviction-interval-timer-in-ms: 1000
eureka.server.wait-time-in-ms-when-sync-empty: 1000
It's due to Eureka's self-preservation mode. Eureka servers will stop the eviction of all instances if the number of heartbeats renewals is below the expected threshold. The warning in your Eureka servers shows this situation happened.
Please try to adjust the below property. 85% is the default value. First, just try to lower the below property like 0.50
eureka.renewalPercentThreshold=0.85
Alternatively, you can disable self-preservation mode with the below property.
eureka.enableSelfPreservation=false
Note
Basically, all Eureka client unregister itself when it shuts down. If it unregisters itself successfully, the above problem will not happen.
Unfortunately, sometimes the Spring Cloud based Eureka client doesn't unregister itself when it shuts down and the symptom is different based on the Spring Cloud version. Dalston and Edgware release unregister itself well in most cases. But Finchley releases seem not to unregister itself now.
Also, you start to run MANY instances in your Eureka environment, the above message will disappear because just one or two instances shutdown will not reach the threshold.
You can find more information about self-preservation mode here

How to delay Eureka client registration with Eureka Server?

I have a Spring Boot application which is also a Eureka client. The normal behavior of the application is to register with Eureka server on start up as UP. I have a requirement that the application shouldn't register with the Eureka server until smoke testing is completed during deployment.
Is there a way to delay the registration with Eureka Server or register as OUT_OF_SERVICE with some type of configuration changes? I am aware of the Eureka REST endpoints to register, unregister, and change status.
Setting eureka.instance.initial-status=OUT_OF_SERVICE will register the service with that status.
I had a similar case where I needed my service to perform some preprocessing before indicating that it was available. I did this by implementing a custom HealthIndicator that starts with a state of OUT_OF_SERVICE and transitions to UP once all of the preprocessing completed. This always seemed a hack to me but it works. Hopefully, Spencer can provide better guidance since he is an author in the Spring ecosystem.
Are you looking for;
eureka.client.initialInstanceInfoReplicationIntervalSeconds=<some N seconds>
This property specifies the initial delay before the clients send health status i.e. UP etc.

Expected #RefreshScope behaviour

I've encountered an issue with #RefreshScope and it's behaviour. Two main queries:
When the refresh endpoint is invoked, the service effectively restarts and unregisters, then re-registers with Eureka. I thought refreshing the scope would in the main be non-service affecting?
My service starts on a random port, i.e. I've set server.port to be 0 in my properties. The restart mentioned above changes initial value assigned to the server port, and changes it to be 0 for the purpose of registering with Eureka. This means the service is effectively uncontactable to any Ribbon/eureka aware load balancer.
See my sample project here:
https://github.com/KramKroc/refreshscope
Thanks to #DaveSyer I was able to get to the bottom of this issue. In my bootstrap.yml in sample-service (see https://github.com/KramKroc/refreshscope) I had the following line:
eureka:
instance:
nonSecurePort: ${server.port:8082}
This was incorrect as it caused the service to re-register with eureka on the server.port (which was set to zero) or 8082 if not defined. Removing the nonSecurePort entry allowed the service to be refreshed and still be registered with the correct (random) port in Eureka.

Websphere SOAP timeout

From EJB transaction I am calling remote site using SOAP. Remote server is not responding. I got transaction time-out. But I want to get time-out from remote call.
How can I set time-out for SOAP request globally?
How can I set time-out for SOAP request for particular call?
You should be able to configure this using a Policy Set. See the link below for IBM's documentation on the topic.
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fae%2Frwbs_jaxwstimeouts.html
To globally set timeout, you may use HTTP transport custom properties for web services applications. The timeout you're looking for here is timeout. This is by default 300 seconds (which is more than global transaction timeout default value, which is 120 seconds, hence you receive a transaction time-out).
If you are using JAX-RPC, make sure you are at a patch level containing fix for PM60752 (6.1.0.45, 7.0.0.25, 8.0.0.5 and 8.5.0.1).
As indicated at Nick's answer, you have alternative methods to configure timeouts if you are using the newer JAX-WS stack.
When using JAX-RPC you may set timeout for a particular call endpoint as explained in article Setting the timeout value for a JAX-RPC Web Service client. For JAX-WS you may use bindings or go for one of the solutions at How to Set Timeout for JAX-WS WebService Call.
One thing to keep in mind when configuring timeouts for web services is that web service transport depends on HTTP transport (assuming SOAP over HTTP), and in turn that depends on TCP transport, all of which are configurable for various timeouts. The relations between these layers and solutions to common problems are outlined at Common Timeouts effecting Web Services, HTTP and SOAP clients article.

Resources