- Calling Kamon.start() in the before block causes erratic behavior in Kamon. I don't know why this is. But it is. We should only call Kamon.start() only for tests that require it.
- Stream monitoring was causing exceptions to be swallowed.
- Stream monitoring started with the first element to flow through the stream; this meant that streams that have only one element will have a duration of close to 0.
Details
modify test locally to loop it 1000 times to assert flakiness is gone
Diff Detail
- Repository
- rMARATHON marathon
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
You can create a DC/OS with your patched Marathon by creating a new pull
request with the following changes in buildinfo.json:
"url": "https://downloads.mesosphere.io/marathon/snapshots/marathon-1.5.0-SNAPSHOT-670-g762a11f.tgz", "sha1": "38be33908835009efb9e0c35757b838b4e5e3be1"
\\ ٩( ᐛ )و //
I wonder why java.time.Clock and not mesosphere.marathon.core.base.Clock. Otherwise that looks great and it also doesn't fail in my local loop. Thx!
src/main/scala/mesosphere/marathon/metrics/HistogramTimer.scala | ||
---|---|---|
30 | clock.instant instead of Option[Long] is neat. But I wonder why java.time.Clock and not our own mesosphere.marathon.core.base.Clock which we use everywhere else? | |
45 | I wonder what kind of errors we swallowed here previously... |
src/main/scala/mesosphere/marathon/metrics/HistogramTimer.scala | ||
---|---|---|
30 | ...because our Clock has ms precision :( |
src/main/scala/mesosphere/marathon/metrics/HistogramTimer.scala | ||
---|---|---|
22 | curious: why was final removed? |
curious: why was final removed?