[
https://issues.apache.org/jira/browse/MESOS-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551804#comment-14551804
]
Vinod Kone commented on MESOS-2735:
-----------------------------------
Thanks Ben for the comments.
I think the main motivations for the push model were to 1) make the writing of
the slave logic (interfacing with estimator) simple and 2) make the writing of
estimator module simple.
Originally, with the pull model, it looked like we need to have 2 intervals
within the slave: one for slave sending estimates to the master and one for
slave getting estimates from the estimator. But if we assume that the
estimators will be well behaved then we don't need an interval for the latter.
The other issue, as you discussed in your comment, was about DoS. It *looked*
like both the push and pull model had the same scope for DoS on the slave, so
we didn't find a compelling a reason to go for pull because push was easier to
implement on both sides of the interface. I said *looked*, because after
processing your comments, I realized that the DoS behavior is different in push
vs pull. In a push model a misbehaving estimator could do head of line blocking
of other messages enqueued on the slave's queue, whereas in the pull model head
of line blocking is not possible because the next (deferred) pull will be
enqueued behind all the other messages.
So, I'm ok going with pull for safety. Also, the composition argument can't be
denied.
Btw, the inspiration for the push model came from the allocator (and to a
lesser extent Mesos class) which I think is very close to the estimator in
terms of interactions. [~jieyu], ok with this?
> Change the interaction between the slave and the resource estimator from
> polling to pushing
> --------------------------------------------------------------------------------------------
>
> Key: MESOS-2735
> URL: https://issues.apache.org/jira/browse/MESOS-2735
> Project: Mesos
> Issue Type: Bug
> Reporter: Jie Yu
> Assignee: Jie Yu
> Labels: twitter
>
> This will make the semantics more clear. The resource estimator can control
> the speed of sending resources estimation to the slave.
> To avoid cyclic dependency, slave will register a callback with the resource
> estimator and the resource estimator will simply invoke that callback when
> there's a new estimation ready. The callback will be a defer to the slave's
> main event queue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
