[ 
https://issues.apache.org/jira/browse/MESOS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14605408#comment-14605408
 ] 

Adam B commented on MESOS-2110:
-------------------------------

Committed the feature. There's still a pending review to update the tests: 
https://reviews.apache.org/r/35958/

commit 6cd28dd9154a1a28ff0756078cb776c221d025d1
Author: Adam B <[email protected]>
Date:   Mon Jun 29 02:59:59 2015 -0700

    Added Configurable Slave Ping Timeouts
    
    Added new --slave_ping_timeout and --max_slave_ping_timeouts flags
    to mesos-master to supplement the DEFAULT_SLAVE_PING_TIMEOUT (15secs)
    and DEFAULT_MAX_SLAVE_PING_TIMEOUTS (5).
    
    These can be extended if slaves are expected/allowed to be down for
    longer than a minute or two.
    
    Slave will receive master's ping timeout in SlaveRe[re]gisteredMessage.
    
    Beware that this affects recovery from network timeouts as well as
    actual slave node/process failover.
    
    Also fixed the log message in recoveredSlavesTimeout() to correctly
    reference flags.slave_reregister_timeout instead of the unrelated
    ping timeouts.
    
    Review: https://reviews.apache.org/r/29507

> Configurable Ping Timeouts
> --------------------------
>
>                 Key: MESOS-2110
>                 URL: https://issues.apache.org/jira/browse/MESOS-2110
>             Project: Mesos
>          Issue Type: Improvement
>          Components: master, slave
>            Reporter: Adam B
>            Assignee: Adam B
>              Labels: master, mesosphere, network, slave, timeout
>
> After a series of ping-failures, the master considers the slave lost and 
> calls shutdownSlave, requiring such a slave that reconnects to kill its tasks 
> and re-register as a new slaveId. On the other side, after a similar timeout, 
> the slave will consider the master lost and try to detect a new master. These 
> timeouts are currently hardcoded constants (5 * 15s), which may not be 
> well-suited for all scenarios.
> - Some clusters may tolerate a longer slave process restart period, and 
> wouldn't want tasks to be killed upon reconnect.
> - Some clusters may have higher-latency networks (e.g. cross-datacenter, or 
> for volunteer computing efforts), and would like to tolerate longer periods 
> without communication.
> We should provide flags/mechanisms on the master to control its tolerance for 
> non-communicative slaves, and (less importantly?) on the slave to tolerate 
> missing masters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to