NodeMetricSpec possibly too strict?
[info] MetricValuesSpec:
[info] NodeMetrics.MetricValues
[info] - must extract expected metrics for load balancing (1 millisecond)
[info] - extract expected MetricValue types for load balancing *** FAILED *** (10 milliseconds)
[info] 1007029083 was not less than or equal to 1007026176 (MetricValuesSpec.scala:43)
So it seems that the committed memory was slightly larger than the allowed max. Is that a bug somewhere or shall the test be more lenient?
Leave a comment
on 2012-12-13 03:36 *
By Patrik Nordwall
Assigned to set to Patrik Nordwall
Status changed from New to Accepted
This should not be possible, according to javadoc of java.lang.management.MemoryUsage
" The amount of used and committed memory will always be less than or equal to max if max is defined"
There is a check of this in MemoryUsage constructor
but there is another constructor in MemoryUsage that takes CompositeData parameter, and that constructor doesn't have this check.
I can't see that we do anything wrong. We grab those values from ManagementFactory.getMemoryMXBean.getHeapMemoryUsage.
I don't think it is important, so I suggest that we remove the assert that checks 'committed must be <= (max)'
OK?
" The amount of used and committed memory will always be less than or equal to max if max is defined"
There is a check of this in MemoryUsage constructor
if (max >= 0 && committed > max) {
throw new IllegalArgumentException( "committed = " + committed +
" should be < max = " + max);
}
but there is another constructor in MemoryUsage that takes CompositeData parameter, and that constructor doesn't have this check.
I can't see that we do anything wrong. We grab those values from ManagementFactory.getMemoryMXBean.getHeapMemoryUsage.
I don't think it is important, so I suggest that we remove the assert that checks 'committed must be <= (max)'
OK?