Spring Cloud Netflix 503 Service Unavailable for 90 seconds after restart of client

Hi,

We are using the Hoxton version of Cloud. We have a Gateway and a number of micro-services / clients all linked via Eureka. When restarting a client (generally in STS while developing), it takes around ~90 seconds get from HTTP 503 to 200.

Following the advice on the reference document "Why is it so slow to register a service", it suggests changing the lease-renewal-interval-in-seconds to a lower value, but this seems to have no effect.

Is there another way to reduce the delay?

The client(s) are defined as;

eureka:
  client:
    service-url:
      default-zone: http://myserver:8760/eureka
  instance:
    lease-renewal-interval-in-seconds: 5

The server is running in "standalone" mode and defined as;

server:
  port:8760
eureka:
  client:
     allow-redirects: true
     register-with-eureka: false
     fetch-registry: false
     service-url:
       default-zone: http://myserver:8760/eureka

Comment From: spencergibb

If you are using ribbon there are also caches as well as timing on the eureka server. Maybe @marcingrzejszczak has some ideas?

Comment From: lafual

I am not explicitly using Ribbon. My POMs just have spring-cloud-starter-netflix-eureka-client or -server. The YML has no reference to Ribbon and I am not using @FeignClient which I understand can affect Ribbon. However, I do see references to Ribbon in my logs, so I assume that it being invoked in some default manner.

Comment From: spencergibb

I believe that brings in ribbon by default, though you've not said what versions you are using.

Comment From: lafual

Hoxton RC.1

Comment From: spencergibb

That is a release candidate (RC). Please try with Hoxton.SR2

Comment From: lafual

Apologies, I answered from memory while off-line from my projects. The versions are actually Hoxton.RELEASE and Boot 2.2.2.RELEASE

Comment From: spencergibb

My request still stands

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: lafual

Please be patient. I am working off-site because of some virus ;-) I assume now that I should re-test with SR3?

Comment From: OlgaMaciaszek

Yes, @lafual Please, retest with Hoxton.SR3.

Comment From: lafual

My apologies for taking time to get this tested. I am currently working offsite and have had to make an .m2 on my on PC including all dependencies for all projects and then have the "super" .m2 imported into our work systems. This is taking longer than expected as I have had to retry this a number of times, due to various oversights and screw-ups.

I appreciate you patience on this matter. I hope to have the files in place sometime next week and then re-check.

In the meantime, can you please confirm that the parameters that I quoted at the top of this post are indeed the correct parameters in order to reduce the 503 time?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: lafual

I have still not managed to get our servers updated with Hoxton.SR3 (grr).

However, on closer inspection, it seems that problem is most prevalent when running from Spring Tool Suite. Using Hoxton.RELEASE on a "real" server with lease-renewal-interval-in-seconds: 5 and restarting the micro-service (which is running as a Windows service) - the 503 stops after about 10-15 seconds.

The Cloud documentation does say this parameter is not entirely accurate as there are other factors at play. However 10-15 seconds is far more reasonable than the 90 seconds I am getting on STS with the same Cloud version.

Does it seem feasible, that STS could be the issue?

Comment From: OlgaMaciaszek

I'm not sure why that would be happening - can verify it, but will need a minimal, complete, verifiable example that reproduces the issue with recent supported release train versions, such as Hoxton.SR3.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: lafual

A bump to keep this issue open. I am still off-site like so many people. I have finally got Boot 2.2.6 and SR3 through our site virus and vulnerability checkers. I will be re-building the projects and re-deploying them tonight. Thank you for your patience on this matter.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: lafual

I finally got Boot 2.2.6 / Hoxton.SR3 installed and distributed. lease-renewal-interval-in-seconds: 5 is now effectively down from 90 seconds to 5-15 seconds. The reference manual does explain that this figure is not accurate. The performance is much better. Thanks for you patience. This case can remain closed.