Re: [1/6] mesos git commit: Fixed a memory leak in the scheduler driver.

+1 Refer to this doc for the detail of deleting null: http://www.cplusplus.com/reference/new/operator%20delete/ Thanks Klaus > On Mar 30, 2016, at 07:24, Neil Conway wrote: > > On Tue, Mar 29, 2016 at 7:19

Re: [1/6] mesos git commit: Fixed a memory leak in the scheduler driver.

On Tue, Mar 29, 2016 at 7:19 PM, wrote: > --- a/src/sched/sched.cpp > +++ b/src/sched/sched.cpp > @@ -1808,6 +1808,10 @@ MesosSchedulerDriver::~MesosSchedulerDriver() > delete process; >} > > + if (credential != NULL) { > +delete credential; > + } `delete`

Re: Ordering guarantee of future.onAny callbacks

I don't believe we have made this assumption often, and I'm not convinced it's a problem in Future. Why would one make such an assumption in the first place? It seems brittle, especially when callbacks are executed in deferred contexts that Future is unaware of. It also limits our flexibility

[GitHub] mesos pull request: Fixing invalid element in UI

Github user jmlvanre commented on the pull request: https://github.com/apache/mesos/pull/94#issuecomment-202839170 ``` commit 299f07a4e534f7a01a6b933d26f8935a327b5e99 Author: Sjoerd Mulder Date: Tue Mar 29 13:18:49 2016 +0200 Fixed UI

[GitHub] mesos pull request: Fixing invalid element in UI

GitHub user sjoerdmulder opened a pull request: https://github.com/apache/mesos/pull/94 Fixing invalid element in UI Caused that the table was rendered to wide. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sjoerdmulder/mesos

[GitHub] mesos pull request: Fixing invalid element in UI

Github user sjoerdmulder closed the pull request at: https://github.com/apache/mesos/pull/94 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] mesos pull request: Fixing invalid element in UI

Github user jmlvanre commented on the pull request: https://github.com/apache/mesos/pull/94#issuecomment-202839888 @sjoerdmulder can you close this PR? I've committed to head. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on

Re: Ordering guarantee of future.onAny callbacks

@Jie, if the target processes in “.onAny(defer())” are the same, is it still un-ordered? > On Mar 29, 2016, at 09:19, Qian Zhang wrote: > > So the point is, if the state of the future is set to READY between > .onAny(callback_A) and .onAny(callback_B) and before callback_A

Re: RFC: RevocableInfo Changes

Answer inline :). > On Mar 29, 2016, at 05:25, Niklas Nielsen wrote: > > Echoing Ben Mahler's comment. I still don't find the ThrottleInfo very > intuitive. [Klaus]: Not sure which one is better: "ScavengeInfo"/ "BestEffortInfo"/“ThrottleableInfo” :). > Did you discuss the

Re: Ordering guarantee of future.onAny callbacks

>can we fix the problem? +1 And I think need make sure all other callbacks ordering guarantee as well. How about fill a ticket for this? One approach I could think is we always put the callback to callbacks vector and trigger it run if status != PENDING. On Tue, Mar 29, 2016 at 5:41 PM, Joris Van

Re: Ordering guarantee of future.onAny callbacks

Rather than saying we shouldn't make this assumption (which I assume has already been made in places, and will likely be made again), can we fix the problem? There's a `TODO` already suggesting running the callback in a separate execution environment. We could also synchronize with thread setting

Re: Build Mesos on Windows

CMake build currently fails on Linux, so I am working on fixing the Agent build before sending the review for the modified docker_build.sh On 27 March 2016 at 09:39, Juan Larriba wrote: > OK Vinod, I will work on it. > > On 26 March 2016 at 20:45, Vinod Kone