> On April 5, 2013, 7:03 p.m., Ben Mahler wrote:
> > src/slave/slave.cpp, line 1650
> > <https://reviews.apache.org/r/10278/diff/1/?file=277810#file277810line1650>
> >
> >     You're calling get() without the Option having a value? This looks like 
> > it will fail the assertion in Option::get.

We set it right above this statement!


> On April 5, 2013, 7:03 p.m., Ben Mahler wrote:
> > src/slave/slave.cpp, line 1698
> > <https://reviews.apache.org/r/10278/diff/1/?file=277810#file277810line1698>
> >
> >     What is the TODO to fix this "hack"?
> >     
> >     I'm missing the context so I don't see why we have to do this change? 
> > Can you elaborate in the review description?

This was a long standing bug. As the comment states, if we don't have any 
pending tasks for a terminated executor, we were incorrectly assuming the 
executor as non-command executor.

The proper way to fix this is to checkpoint this information, so that the slave 
can always know about an executor's type (command executor or not) even after a 
slave restart. But, we didn't want to checkpoint/recover yet another file. So, 
implemented a hacky solution to deduce it from the command.


- Vinod


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


On April 4, 2013, 1:20 a.m., Vinod Kone wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10278/
> -----------------------------------------------------------
> 
> (Updated April 4, 2013, 1:20 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   src/slave/slave.cpp 325231458a6883019436e7cc5a37f85f0f5735fa 
> 
> Diff: https://reviews.apache.org/r/10278/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Reply via email to