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 | [email protected] | http://k82.me On Tue, Jan 5, 2016 at 10:47 PM, sujz.buaa <[email protected]> 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 ! >
