> On March 1, 2016, 12:48 p.m., Alexander Rukletsov wrote: > > src/master/allocator/mesos/hierarchical.cpp, lines 268-272 > > <https://reviews.apache.org/r/43881/diff/9/?file=1273639#file1273639line268> > > > > Does it make sense to wrap framework-related metrics in a separate > > struct in metrics and hide `process::metrics::add` there? You can look here > > for inspiration: > > https://github.com/apache/mesos/blob/0fd95ccc54e4d144c3eb60e98bf77d53b6bdab63/src/master/metrics.hpp#L81
That's something I also thought about. This might be something useful more generally, so I suggest to look at this independently of this series and fix everywhere. What I find slightly suboptimal about the wrapper you linked to is that it would `add` and `remove` the same metric even when the wrapper is just copied (the `MetricProcess` uses just the name of the `Metric` to check identity). The calls `add` and `remove` return `Future<Nothing>`s to indicate success or failure but we cannot propagate that information in an RAII way in mesos (no exceptions). I think one would either need a type w/o copy ctr and a specific move ctr, or a more complicated infrastructure of e.g., handlers and shared metrics in the back. > On March 1, 2016, 12:48 p.m., Alexander Rukletsov wrote: > > src/tests/hierarchical_allocator_tests.cpp, line 2463 > > <https://reviews.apache.org/r/43881/diff/9/?file=1273640#file1273640line2463> > > > > I'm an ESL as well, but "to" sounds better than "towards" to me. I choose *towards* since I am referring the *`framework1`'s quota*, but that might be an overly mechanic use of the language typical a German ESL user. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/43881/#review121421 ----------------------------------------------------------- On March 2, 2016, 4:43 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/43881/ > ----------------------------------------------------------- > > (Updated March 2, 2016, 4:43 p.m.) > > > Review request for mesos, Alexander Rukletsov and Ben Mahler. > > > Bugs: MESOS-4719 > https://issues.apache.org/jira/browse/MESOS-4719 > > > Repository: mesos > > > Description > ------- > > See summary. > > > Diffs > ----- > > docs/monitoring.md 827f7073204fcf8575ca980a5571c8be4f5e4110 > src/master/allocator/mesos/hierarchical.cpp > 24fa50f62dec10ed43089297473cc386d6ba2f78 > src/master/allocator/mesos/metrics.hpp PRE-CREATION > src/master/allocator/mesos/metrics.cpp PRE-CREATION > src/tests/hierarchical_allocator_tests.cpp > 5f771f02db9bd098f3cd36730cd84bf2f5e87a33 > > Diff: https://reviews.apache.org/r/43881/diff/ > > > Testing > ------- > > make check (OS X) > > I confirmed that this does not lead to general performance regressions in the > allocator; this is partially expected since the added code only inserts > metrics in the allocator while the actual work is perform asynchronously. > These tests where performed with > `HierarchicalAllocator_BENCHMARK_Test.DeclineOffers` on an optimized build > under OS X using clang(trunk) as compiler. > > > Thanks, > > Benjamin Bannier > >
