New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eureka seems to do not recalculate numberOfRenewsPerMinThreshold during evicting expired leases #2407
Comments
Hi, The "Renews threshold" is decreased if a service is shutdown gracefully. Then, before going down it calls If, for instance, a service was killed by SIGKILL then the " In my case, I tested this issue in the following way:
After repeating the step 3 many times I got a big " |
@p-zalejko I've been following this discussion, is this problem solved? |
Hi, @holy12345 . I think it isn't. I tested a milestone version (2.x) and it behaves the same. |
@p-zalejko Hi,
First of all, this scheduled task defaults to every 15 minutes. if self-preservation is off, the Do I understand it correctly? Best wishes. |
Hi @holy12345, I think you are right: If the self-preservation is turned off ( But if it is enabled I would expect that the Unfortunately, in terms of the |
@p-zalejko First of all thank you for your reply :) You're right, count is 0 too in my test environment.What i am trying to do next is to understand why the count is zero, maybe solve this problem, and the problem you ask is solved.If there is progress, I will inform you first, best wishes! |
@p-zalejko Hello, is your eureka server one? I think it should not be a cluster. If it is not a cluster, the value actually obtained is an empty list. best wishes |
i have to follow up on this one, does this mean we are not expected to turn on "self-preservation mode" for eureka server in a none-cluster mode? thanks. @holy12345 |
Closing this due to inactivity. Please re-open if there's more to discuss. |
@spencergibb This issue seems to persist as of latest version (1.9.12). I came across this as well and did some digging on the source, it seems to go to the difference between a graceful shutdown and a non-graceful shutdown (e.g. the EvictTask is removing the instances, rather than a call to cancel a lease). Ultimately, the AbstractInstanceRegistry.evict method makes a call to "internalCancel" which does not modify the "expectedNumberOfClientsSendingRenews" count. Now we have the "count" of total instances from the update task, which is calculated in PeerAwareInstanceRegistryImpl.updateRenewalThreshold by cycling through all apps and then instances of each app and keeping a tally, with one less for the evicted instance, but the "expectedNumberOfClientsSendingRenews" does not account for that evicted instance. For a graceful shutdown of a service, PeerAwareInstanceRegistryImpl.cancel seems to be called, which decrements "expectedNumberOfClientsSendingRenews" properly. I would've expected the variable to be decremented regardless of whether it's an eviction from the timer task or a graceful shutdown. The best place seems to be before internalCancel is called in AbstractInstanceRegistry.evict. Thoughts? |
@Jeffrey-Hassan this has been fixed in |
See #3743 |
Hi
in my test environment services are restarts frequently by mesos-marathon without unregistration(SIGKILL)
so i noticed that eureka instance is in Self-preservation-mode frequently.
eureka has 65 registered services ,but numberOfRenewsPerMinThreshold is 368
that seems to be incorrect.
i found that numberOfRenewsPerMinThreshold decreased only via REST-API
but when lease expired
numberOfRenewsPerMinThreshold does not decreases,
so numberOfRenewsPerMinThreshold does not correlate with real instance count and expectedNumberOfRenewsPerMin
some greps:
REGISTERD
EXPIRED
RENEWAL
The text was updated successfully, but these errors were encountered: