Till Toenshoff created MESOS-2360:
-------------------------------------
Summary: Slave may send multiple, almost concurrent registration
requests to the master.
Key: MESOS-2360
URL: https://issues.apache.org/jira/browse/MESOS-2360
Project: Mesos
Issue Type: Bug
Reporter: Till Toenshoff
Triggered by an issue Alexander stumbled across in
https://issues.apache.org/jira/browse/MESOS-2355, I wanted to find out on why
the Slave was allowed to send out multiple, parallel registration requests.
When looking at the code, one part got my attention:
{noformat}
// Retry registration if necessary.
Duration next = std::min(
duration * ((double) ::random() / RAND_MAX),
REGISTER_RETRY_INTERVAL_MAX);
{noformat}
[src/slave.cpp, slave::doReliableRegistration, line 1040 ff]
So this does allow {{next}} to be something equal or very close to 0. Such zero
delay will cause immediate retries which might (with a bit of tough luck) again
trigger an immediate retry a.s.o.. The delay will, for these cases, be
determined by the full cycle-frequency of libprocess.
Why was this implemented without a flooring limit - say e.g. 1second?
While MESOS-2355 got a proper fix for this scenario in a test, the global issue
remains to get clarified, I think.
Should we add such floor limit to prevent pointless (almost) concurrent
registration requests?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
