danny0405 commented on code in PR #19819:
URL: https://github.com/apache/hudi/pull/19819#discussion_r3914445188
##########
hudi-client/hudi-flink-client/src/test/java/org/apache/hudi/client/common/TestHoodieFlinkEngineContext.java:
##########
@@ -89,4 +99,40 @@ public void testMapToPair() {
Assertions.assertEquals(resultMap.get("spark"), resultMap.get("flink"));
}
+ @Test
+ public void testMapGroupsByKeyUsesDedicatedForkJoinPool() {
+ HoodiePairData<Integer, Integer> input =
HoodieListPairData.eager(Arrays.asList(
+ Pair.of(1, 3), Pair.of(1, 1), Pair.of(2, 4), Pair.of(2, 2), Pair.of(3,
5)));
+ Set<ForkJoinPool> executingPools = ConcurrentHashMap.newKeySet();
+ AtomicBoolean executedOutsideForkJoinPool = new AtomicBoolean(false);
+
+ HoodieData<Integer> result = context.mapGroupsByKey(input, values -> {
+ ForkJoinPool executingPool = ForkJoinTask.getPool();
+ if (executingPool == null) {
+ executedOutsideForkJoinPool.set(true);
+ } else {
+ executingPools.add(executingPool);
+ }
+ return values;
Review Comment:
This records the pool only while `processFunc` is invoked, but the
regression is specifically about keeping the complete lazy pipeline—including
consumption of the iterator returned by `processFunc`—inside the dedicated
pool. Could the test return a small wrapper iterator whose `hasNext`/`next`
also records `ForkJoinTask.getPool()`? That would catch a future regression
where the function is invoked in the dedicated pool but `flatMap`/collection
escapes it.
##########
hudi-client/hudi-flink-client/src/test/java/org/apache/hudi/client/common/TestHoodieFlinkEngineContext.java:
##########
@@ -89,4 +99,40 @@ public void testMapToPair() {
Assertions.assertEquals(resultMap.get("spark"), resultMap.get("flink"));
}
+ @Test
+ public void testMapGroupsByKeyUsesDedicatedForkJoinPool() {
+ HoodiePairData<Integer, Integer> input =
HoodieListPairData.eager(Arrays.asList(
+ Pair.of(1, 3), Pair.of(1, 1), Pair.of(2, 4), Pair.of(2, 2), Pair.of(3,
5)));
+ Set<ForkJoinPool> executingPools = ConcurrentHashMap.newKeySet();
+ AtomicBoolean executedOutsideForkJoinPool = new AtomicBoolean(false);
+
+ HoodieData<Integer> result = context.mapGroupsByKey(input, values -> {
+ ForkJoinPool executingPool = ForkJoinTask.getPool();
+ if (executingPool == null) {
+ executedOutsideForkJoinPool.set(true);
+ } else {
+ executingPools.add(executingPool);
+ }
+ return values;
+ }, Arrays.asList(1, 2, 3), false);
+
+ Assertions.assertFalse(executedOutsideForkJoinPool.get());
+ Assertions.assertEquals(1, executingPools.size());
+ Assertions.assertNotSame(ForkJoinPool.commonPool(),
executingPools.iterator().next());
+ Assertions.assertEquals(3,
executingPools.iterator().next().getParallelism());
+ List<Integer> actual = result.collectAsList();
+ Collections.sort(actual);
+ Assertions.assertEquals(Arrays.asList(1, 2, 3, 4, 5), actual);
Review Comment:
Could we add a case where `processFunc` throws and assert that the failure
is wrapped by `executeParallelStream` as a `HoodieException` with the original
cause? Before this fix, that exception occurred during the terminal operation
outside the helper and bypassed its wrapping; covering it would lock down the
other observable behavior corrected by this change.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
