Hey Tom, to be clear, the best-effort messaging primitive will remain
either way.
What I'm referring to is the fact that we when we see offers for a slave in
the driver, we store each slave's address so that we can send messages
directly to the slave, rather than sending through the master. That
We're using it for streaming realtime logs to the framework. In our short-lived
framework for building Docker images, the executor streams back stdout/stderr
logs from the build to the client for ease of use/debugging and the
executor-framework best-effort messaging stuff made this effortless.
The existing Mesos API provides unreliable messaging passing for framework
- executor communication:
-- Schedulers can call 'sendFrameworkMessage(executor, slave, data)' on
the driver [1], this sends a message to the executor. This has a
best-effort optimization to bypass the master, and send the
3 matches
Mail list logo
