> On Oct. 14, 2014, 4:44 p.m., Dominic Hamon wrote:
> > docs/reconciliation.md, line 35
> > <https://reviews.apache.org/r/26669/diff/1/?file=719858#file719858line35>
> >
> >     can we say here that it's the responsibility of the master and work 
> > toward that goal?

If the client side (today this is the driver) sends a message on some socket 
that closes, that message is dropped and the master is unaware. For now I think 
framework developers should be aware of this.

With the new API we'll definitely need to carefully reconsider whether we can 
use a bidirectional socket and whether the responsibility can reside solely on 
the Master. I have not thought through that, so I'm not sure.


> On Oct. 14, 2014, 4:44 p.m., Dominic Hamon wrote:
> > docs/reconciliation.md, line 48
> > <https://reviews.apache.org/r/26669/diff/1/?file=719858#file719858line48>
> >
> >     if there's a jira ticket for this, please link it.

I'll just to remove this specific reference for now, since we don't have the 
new API available to make this kind of thing possible.


> On Oct. 14, 2014, 4:44 p.m., Dominic Hamon wrote:
> > docs/reconciliation.md, line 9
> > <https://reviews.apache.org/r/26669/diff/1/?file=719858#file719858line9>
> >
> >     is there a link to other documentation that could come in here to 
> > describe the programming model in more depth?

Not really, but there should be! :)


> On Oct. 14, 2014, 4:44 p.m., Dominic Hamon wrote:
> > docs/reconciliation.md, line 75
> > <https://reviews.apache.org/r/26669/diff/1/?file=719858#file719858line75>
> >
> >     it's unfortunate that we put the onus on framework developers to manage 
> > this algorithm and the exponential backoff.
> >     
> >     I wonder if we can move to a model where a reconcile request is made 
> > and then a stream of replies is sent including a terminal empty set.
> >     
> >     (this is speculative only, obviously.. i think the document is fine as 
> > it describes the current state).

Yeah, see the discussion on the mailing list w/ Sharma Podila.

I think the ergonomics could definitely be improved, but then what does the 
framework do if it finds it did not receive the expected updates? Would there 
still be a retry on the framework side to be resilient in this case?

At least going forward with pure language bindings, someone could implement 
this technique and it can be shared across different frameworks.


- Ben


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26669/#review56539
-----------------------------------------------------------


On Oct. 14, 2014, 12:34 a.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26669/
> -----------------------------------------------------------
> 
> (Updated Oct. 14, 2014, 12:34 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Niklas Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-681
>     https://issues.apache.org/jira/browse/MESOS-681
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Please see here for rendered markdown, will be easier to review:
> https://gist.github.com/bmahler/18409fc4f052df43f403
> 
> Please send your high level thoughts :)
> 
> 
> Diffs
> -----
> 
>   docs/reconciliation.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/26669/diff/
> 
> 
> Testing
> -------
> 
> 
> N/A
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to