> On May 7, 2015, 6:34 p.m., Ben Mahler wrote:
> > Hm, I looked at MESOS-2633, that's only about moving implementation out?
> >
> > Could we get some more context on this change? What motivated it? Is there
> > a bug? When can it occur? What happens if it does?
There was no Jira about this change: it was a TODO in the code, which I thought
looked trivial enough that was worth doing (my general rule has always been: if
it takes longer to create a ticket than actually writing the code to solve it,
just do it :)
As for the reasons for the ToDo in the first place, I'll leave it up to @adam
to address that - I was merely executing on his wishes...
Thanks for noting that, though: I have updated the description and elaborated
on the diff description.
- Marco
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33490/#review82867
---
On May 8, 2015, 6:16 p.m., Marco Massenzio wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33490/
> ---
>
> (Updated May 8, 2015, 6:16 p.m.)
>
>
> Review request for mesos, Adam B and Joris Van Remoortere.
>
>
> Repository: mesos
>
>
> Description
> ---
>
> In `Framework::addCompletedTask(const Task& task)` we did not check
> for duplicated tasks, so they could be added more than once.
>
> A simple check has now been added (there is the question of whether the
> `operator ==` on `Task` is too strict, so as
> never to cause a match).
>
> This fixes a TODO I came across as part of the work on MESOS-2633 (no Jira
> tracking this issue)
>
>
> Diffs
> -
>
> src/master/framework.cpp PRE-CREATION
>
> Diff: https://reviews.apache.org/r/33490/diff/
>
>
> Testing
> ---
>
> make check
>
>
> Thanks,
>
> Marco Massenzio
>
>
