zhuzhurk commented on a change in pull request #10341: [FLINK-14974][runtime]
Calculate managed memory fractions with BigDecimal and round down it properly
URL: https://github.com/apache/flink/pull/10341#discussion_r352128673
##########
File path:
flink-streaming-java/src/test/java/org/apache/flink/streaming/api/graph/StreamingJobGraphGeneratorTest.java
##########
@@ -680,17 +683,31 @@ public void
testManagedMemoryFractionForSpecifiedResourceSpec() throws Exception
final JobVertex vertex3 =
jobGraph.getVerticesSortedTopologicallyFromSources().get(2);
final StreamConfig sourceConfig = new
StreamConfig(vertex1.getConfiguration());
- assertEquals(0.1,
sourceConfig.getManagedMemoryFractionOnHeap(), 0.000001);
- assertEquals(0.4,
sourceConfig.getManagedMemoryFractionOffHeap(), 0.000001);
+ assertEquals(100.0 / 1100,
sourceConfig.getManagedMemoryFractionOnHeap(), 0.000001);
+ assertEquals(40.0 / 110,
sourceConfig.getManagedMemoryFractionOffHeap(), 0.000001);
final StreamConfig map1Config = Iterables.getOnlyElement(
sourceConfig.getTransitiveChainedTaskConfigs(StreamingJobGraphGeneratorTest.class.getClassLoader()).values());
- assertEquals(0.3, map1Config.getManagedMemoryFractionOnHeap(),
0.000001);
- assertEquals(0.5, map1Config.getManagedMemoryFractionOffHeap(),
0.000001);
+ assertEquals(300.0 / 1100,
map1Config.getManagedMemoryFractionOnHeap(), 0.000001);
+ assertEquals(60.0 / 110,
map1Config.getManagedMemoryFractionOffHeap(), 0.000001);
final StreamConfig map2Config = new
StreamConfig(vertex2.getConfiguration());
- assertEquals(0.6, map2Config.getManagedMemoryFractionOnHeap(),
0.000001);
- assertEquals(0.1, map2Config.getManagedMemoryFractionOffHeap(),
0.000001);
+ assertEquals(700.0 / 1100,
map2Config.getManagedMemoryFractionOnHeap(), 0.000001);
+ assertEquals(10.0 / 110,
map2Config.getManagedMemoryFractionOffHeap(), 0.000001);
+
+ final double remainingFractionOnHeap = BigDecimal.ONE
+
.subtract(BigDecimal.valueOf(sourceConfig.getManagedMemoryFractionOnHeap()))
Review comment:
Yes, I also wanted to do that but fails to since the double precision made
the sum 1.0000000000000001 to be 1.0 again, but subtraction can reveal this
issue, and subtraction is actually what would happen in production resource
matching.
Now I have changed the assert to directly compare `BigDecimal` so that there
would be no delta loss due to precision.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
