[
https://issues.apache.org/jira/browse/MESOS-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700904#comment-16700904
]
Vinod Kone commented on MESOS-7564:
-----------------------------------
{quote}
1) The SUBSCRIBE Call is one persistent connection where the executor sends one
Call, and receives a stream of Events. There is currently no Executor->Agent
traffic except the first request. This connection could probably use
heartbeating in both directions. Agent->Executor heartbeats may come in the
form of Events. Executor->Agent heartbeats will need to be something else (like
the heartbeating suggested here: [https://reviews.apache.org/r/69183/] ).
{quote}
Do we really need heartbeats in both directions given it is a single
connection? I would imagine agent -> executor heartbeat events should be enough
like we did with v1 scheduler API?
> Introduce a heartbeat mechanism for v1 HTTP executor <-> agent communication.
> -----------------------------------------------------------------------------
>
> Key: MESOS-7564
> URL: https://issues.apache.org/jira/browse/MESOS-7564
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
> Reporter: Anand Mazumdar
> Assignee: Joseph Wu
> Priority: Critical
> Labels: api, mesosphere, v1_api
>
> Currently, we do not have heartbeats for executor <-> agent communication.
> This is especially problematic in scenarios when IPFilters are enabled since
> the default conntrack keep alive timeout is 5 days. When that timeout
> elapses, the executor doesn't get notified via a socket disconnection when
> the agent process restarts. The executor would then get killed if it doesn't
> re-register when the agent recovery process is completed.
> Enabling application level heartbeats or TCP KeepAlive's can be a possible
> way for fixing this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
