Understanding Eureka Client Cache

Question

I need some help understanding why services registered in Eureka would want to communicate with each other despite not actually running. For instance, I have service A and service B registered in Eureka. If I bring down service B, service A will still try to communicate with service B for 30 seconds to 3 minutes even though it is not running. What is the purpose of this? And is there any way around it? Thank you!

Answer 1

As you know, Netflix is running a huge number of server instances based on Eureka. So The overhead to look up instances via Eureka could be big overhead for Netflix. I guess that that's why Eureka has caches, polling intervals and other feature that cause the delay of refreshing instance status.

Fortunately, you can adjust this delay with the below properties.

• Eureka Server - eureka.server.responseCacheUpdateInvervalMs

  • 30 seconds. Eureka server's APIs have its own cache for response. The default is quite big period. You can decrease this value.

• Eureka Client (API Caller) - eureka.client.registryFetchIntervalSeconds

  • 30 seconds. Eureka client fetches instances status from Eureka server periodically. You can decrease this value.

• Eureka Client (API Provider) eureka.instance.leaseExpirationDurationInSeconds

  • 90 seconds. Each instance that registers to Eureka server can set the expiration duration for itself. Eureka server expires instance if it doesn't receive any heartbeat from Eureka client during this period. As a default, each Eureka client sends the heartbeat every 30s.

If the number of instances that you're running is not so big, you can usually decrease above properties.

There is another property related to this delay.

• eureka.instance.leaseRenewalIntervalInSeconds

This property set the interval of heartbeat for Eureka client. Its default is 30 seconds, but you can't adjust this value because Eureka server has some hardcoded logic that assumes this period is 30 seconds.

Answer 2

I believe you are referring to Eureka's self-preservation mode.

What is the purpose of this?

Self-preservation mode is design to handle short duration network failures. Once the instance is registered, Eureka server is not going to keep the instance in registry forever. It sets a lease renewal policy with the instance when the instances registers for the first time. That policy includes how many heartbeats the instance can miss before it is evicted from registry.

Self-preservation mode is important when you are running multiple Eureka servers .

You can go through this SO question for more details about self-preservation mode.

And is there any way around it?

It is enabled by default. It can be disabled.

You can also adjust a few properties to make sure dead instances are evicted as soon as possible .

Please go through SO question linked above for help on which properties to tweak.