You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by "sujz.buaa" <su...@qq.com> on 2016/01/05 15:47:42 UTC
Why are FrameworkToExecutorMessage and ExecutorToFrameworkMessage transmitted along different paths?
Hi, all:
I am using mesos-0.22.0, I noticed that FrameworkToExecutorMessage is sent along path:
Scheduler->Master->Slave->Executor,
while ExecutorToFrameworkMessage is sent along path:
Executor->Slave->Scheduler,
So is there some reason or benefit for bypassing master while transmitting ExecutorToFrameworkMessage?
One more question, FrameworkToExecutorMessage and ExecutorToFrameworkMessage are instantiated in function SendFrameworkMessage, declaration of SendFrameworkMessage in include/mesos/scheduler.hpp and include/mesos/executor.hpp:
// Sends a message from the framework to one of its executors. These
// messages are best effort; do not expect a framework message to be
// retransmitted in any reliable fashion.
virtual Status sendFrameworkMessage(
const ExecutorID& executorId,
const SlaveID& slaveId,
const std::string& data) = 0;
I guess that protobuf message are transmitted with TCP, so does this comment mean I have to guarantee reliability by myself even with TCP? What's special for these
two messages compared with other protobuf messages, If no, do we have to guarantee reliability all by ourselves?
Thank you very much and best regards !
Re: Why are FrameworkToExecutorMessage and ExecutorToFrameworkMessage
transmitted along different paths?
Posted by Klaus Ma <kl...@gmail.com>.
re different path: that's because Master know the detail of Slave, e.g.
hostname & port; but when Executor send it to Scheduler, Slave has
Scheduler's info to send message.
re FrameworkToExeutorMessage reliability: yes, framework developer need to
guarantee its reliability, e.g. in Master/Slave failover case.
----
Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
Platform Symphony/DCOS Development & Support, STG, IBM GCG
+86-10-8245 4084 | klaus1982.cn@gmail.com | http://k82.me
On Tue, Jan 5, 2016 at 10:47 PM, sujz.buaa <su...@qq.com> wrote:
> Hi, all:
>
>
> I am using mesos-0.22.0, I noticed that FrameworkToExecutorMessage is sent along path:
> Scheduler->Master->Slave->Executor,
> while ExecutorToFrameworkMessage is sent along path:
> Executor->Slave->Scheduler,
>
>
> So is there some reason or benefit for bypassing master while transmitting ExecutorToFrameworkMessage?
>
> One more question, FrameworkToExecutorMessage and ExecutorToFrameworkMessage are instantiated
> in function SendFrameworkMessage,
> declaration of SendFrameworkMessage in include/mesos/scheduler.hpp and include/mesos/executor.hpp:
> // Sends a message from the framework to one of its executors. These
> // messages are *best effort*; do not expect a framework message to be
> // retransmitted in any reliable fashion.
> virtual Status sendFrameworkMessage(
> const ExecutorID& executorId,
> const SlaveID& slaveId,
> const std::string& data) = 0;
>
>
> I guess that protobuf message are transmitted with TCP, so does this comment mean I have to guarantee reliability by myself even with TCP? What's special for these
>
> two messages compared with other protobuf messages, If no, do we have to guarantee reliability all by ourselves?
>
> Thank you very much and best regards !
>
Re: Why are FrameworkToExecutorMessage and ExecutorToFrameworkMessage
transmitted along different paths?
Posted by haosdent <ha...@gmail.com>.
I compare current branch
https://github.com/apache/mesos/blob/master/src/slave/slave.cpp#L3356-L3364
with 0.22
https://github.com/apache/mesos/blob/0.22.2/src/slave/slave.cpp#L2842-L2847
I think if Slave know Framework pid, why I not
send ExecutorToFrameworkMessage from Slave to Scheduler directly.
FrameworkToExecutorMessage have to bypass master is because scheduler don't
have Slave pid and maintain connections between every Slaves.
And for
>I guess that protobuf message are transmitted with TCP, so does this
comment mean I have to guarantee reliability by myself even with TCP?
In some cases in
https://github.com/apache/mesos/blob/master/src/master/master.cpp#L3949,
framework maybe could not receive ExecutorToFrameworkMessage.
>If no, do we have to guarantee reliability all by ourselves
Maybe could use some external systems, kafka or db?
On Tue, Jan 5, 2016 at 10:47 PM, sujz.buaa <su...@qq.com> wrote:
> Hi, all:
>
>
> I am using mesos-0.22.0, I noticed that FrameworkToExecutorMessage is sent along path:
> Scheduler->Master->Slave->Executor,
> while ExecutorToFrameworkMessage is sent along path:
> Executor->Slave->Scheduler,
>
>
> So is there some reason or benefit for bypassing master while transmitting ExecutorToFrameworkMessage?
>
> One more question, FrameworkToExecutorMessage and ExecutorToFrameworkMessage are instantiated
> in function SendFrameworkMessage,
> declaration of SendFrameworkMessage in include/mesos/scheduler.hpp and include/mesos/executor.hpp:
> // Sends a message from the framework to one of its executors. These
> // messages are *best effort*; do not expect a framework message to be
> // retransmitted in any reliable fashion.
> virtual Status sendFrameworkMessage(
> const ExecutorID& executorId,
> const SlaveID& slaveId,
> const std::string& data) = 0;
>
>
> I guess that protobuf message are transmitted with TCP, so does this comment mean I have to guarantee reliability by myself even with TCP? What's special for these
>
> two messages compared with other protobuf messages, If no, do we have to guarantee reliability all by ourselves?
>
> Thank you very much and best regards !
>
--
Best Regards,
Haosdent Huang