> On May 12, 2014, 12:53 p.m., Ben Mahler wrote: > > src/slave/slave.hpp, lines 412-415 > > <https://reviews.apache.org/r/21276/diff/1/?file=577385#file577385line412> > > > > These terminal task state Gauges are only capturing the information > > contained within the slave's cache of terminated executors / tasks. This > > can be unfortunate as these metrics will only reflect our cached > > information, rather than the total number of tasks that reached a terminal > > state. > > > > For example, consider a slave that ran 50,000 tasks to TASK_FINISHED > > through a single executor/framework. This patch will expose > > "tasks_finished" as 300 (MAX_COMPLETED_TASKS_PER_EXECUTOR), rather than as > > 50,000. > > > > Given that we don't store infinite task / executor / framework history > > in the slave, can we change these terminal Gauges to Counters?
the implementation of the gauge was actually double-counting, so in your example it would be 50,300 or so :) Replaced gauges with counters and incremented directly. - Dominic ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21276/#review42735 ----------------------------------------------------------- On May 12, 2014, 1:53 p.m., Dominic Hamon wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21276/ > ----------------------------------------------------------- > > (Updated May 12, 2014, 1:53 p.m.) > > > Review request for mesos and Ben Mahler. > > > Bugs: MESOS-1332 > https://issues.apache.org/jira/browse/MESOS-1332 > > > Repository: mesos-git > > > Description > ------- > > see summary > > > Diffs > ----- > > src/slave/slave.hpp a6efad4763a7180daad63689227b46e196e5e1a9 > src/slave/slave.cpp 3a4ae38e06a1c23daafebf5421d996e649a07ca5 > > Diff: https://reviews.apache.org/r/21276/diff/ > > > Testing > ------- > > make check > > ran locally and manually verified > > > Thanks, > > Dominic Hamon > >
