[
https://issues.apache.org/jira/browse/MESOS-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14546469#comment-14546469
]
Niklas Quarfot Nielsen commented on MESOS-2735:
-----------------------------------------------
Sorry that I am keep banging on this issue, but still not completely convinced
this makes a cleaner API.
Hope you can help me understand.
{quote}
1) This matches the existing allocator interface.
{quote}
But doesn't match many other APIs internally - don't feel this is a strong
argument.
{quote}
2) Slave no longer needs to configure the polling interval. It's up to the
resource estimator to decide when to send estimations.
{quote}
Didn't you agree that it could be done with
updates().then(lambda(&Slave::updateOverestimated, lambda::_1))?
{quote}
3) It avoid the potential issue that "estimator::update()" is blocking. Slave
will hang if "estimator::update()" blocks.
{quote}
If the estimator never updates the "last estimate" in the slave, is the same
effect - no?
Is the problem, that the current design doesn't support the "multiple firing"
problem, where the estimator updates while the callback is being executed?
[~benjaminhindman] Do you have an opinion on 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)
