[jira] [Commented] (FLINK-3385) Fix outer join skipping unprobed partitions

["Greg Hogan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141490#comment-15141490 ] 

Greg Hogan commented on FLINK-3385:
-----------------------------------

Here is the simple function I was using to isolate this case, and constraining available memory with -Xmx200m. What is the best way to force spilling in an automated test?

{code}
	public void testBrokenOuterJoin() throws Exception {
		final int NUMBER_OF_ELEMENTS = 2 * 1000 * 1000;

		final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();
		env.setParallelism(1);

		DataSet<Long> ds1 = env
			.fromParallelCollection(new NumberSequenceIterator(0, NUMBER_OF_ELEMENTS - 1), Long.class);

		DataSet<Long> ds2 = ds1
			.filter(new FilterFunction<Long>() {
				@Override
				public boolean filter(Long value) throws Exception {
					return false;
				}
			});

		DataSet<Long> joinDs = ds1
			.leftOuterJoin(ds2, JoinHint.REPARTITION_HASH_FIRST)
			.where("*")
			.equalTo("*")
			.with(new JoinFunction<Long, Long, Long>() {
				@Override
				public Long join(Long first, Long second) throws Exception {
					return (first == null) ? second : first;
				}
			});

//		List<Long> result = joinDs
//			.collect();
//		Collections.sort(result);

		long count = joinDs
			.count();

		assertEquals(NUMBER_OF_ELEMENTS, count);
	}
{code}

> Fix outer join skipping unprobed partitions
> -------------------------------------------
>
>                 Key: FLINK-3385
>                 URL: https://issues.apache.org/jira/browse/FLINK-3385
>             Project: Flink
>          Issue Type: Bug
>          Components: Distributed Runtime
>            Reporter: Greg Hogan
>            Priority: Critical
>             Fix For: 1.0.0
>
>
> {{MutableHashTable.nextRecord}} performs three steps for a build-side outer join:
> {code}
> 	public boolean nextRecord() throws IOException {
> 		if (buildSideOuterJoin) {
> 			return processProbeIter() || processUnmatchedBuildIter() || prepareNextPartition();
> 		} else {
> 			return processProbeIter() || prepareNextPartition();
> 		}
> 	}
> {code}
> {{MutableHashTable.processUnmatchedBuildIter}} eventually calls through to {{MutableHashTable.moveToNextBucket}} which is unable to process spilled partitions:
> {code}
> 			if (p.isInMemory()) {
> 				...
> 			} else {
> 				return false;
> 			}
> {code}
> {{MutableHashTable.prepareNextPartition}} calls {{HashPartition.finalizeProbePhase}} which only spills the partition (to be read and processed in the next instantiation of {{MutableHashTable}}) if probe-side records were spilled. In an equi-join this is fine but with an outer join the unmatched build-side records must still be retained (though no further probing is necessary, so could this be short-circuited when loaded by the next {{MutableHashTable}}?).
> {code}
> 		if (isInMemory()) {
> 			...
> 		}
> 		else if (this.probeSideRecordCounter == 0) {
> 			// partition is empty, no spilled buffers
> 			// return the memory buffer
> 			freeMemory.add(this.probeSideBuffer.getCurrentSegment());
> 			// delete the spill files
> 			this.probeSideChannel.close();
> 			this.buildSideChannel.deleteChannel();
> 			this.probeSideChannel.deleteChannel();
> 			return 0;
> 		}
> 		else {
> 			// flush the last probe side buffer and register this partition as pending
> 			this.probeSideBuffer.close();
> 			this.probeSideChannel.close();
> 			spilledPartitions.add(this);
> 			return 1;
> 		}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)