Hi All,
I'm trying to test a pipeline that consists of two Flink tasks with a MiniCluster. The 1st task has a WindowAll operator which groups items into batches every second, and the 2nd task does an async operation with each batch and flatMaps the result.
I've whittled it down to the bare bones below. There are two tests:
It seems like a timing issue. If I step through the failing one slowly I can see that the ProcessingTimeTrigger's onElement/onProcessingTime/clear methods do get called, and the asyncInvoke method also gets called, but when I run it the 2nd test fails as it
produces no output. I've tried setting the MiniCluster timeout to 1 day, the same with my AsyncUDF timeout, and sleeping for 3 * window after env.execute but no difference. I'm running this with Flink 1.9.0 and OpenJDK8 on Ubuntu (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10).
Any idea how I can get the 2nd test to wait to process the output?
Thanks 🙂
John.
|
Hi John, The root cause is the collection source exits too fast. The window would also exit without being triggered. You could verify that by waiting a second before releasing the window. For example, insert a map operator between source and window operator. Blocking a second or more in the "close" method of this map operator. You will see the window would work well. Thanks, Biao /'bɪ.aʊ/ On Wed, 18 Dec 2019 at 06:24, John Morrow <[hidden email]> wrote:
|
Thanks Biao!
I tried slowing down the input stream by replacing the env.fromCollection() with a custom SourceFunction (below) which drip feeds the data a bit slower. By the way, in my real scenario the datasource for the pipeline will be a RabbitMQ source.
I do get better results, but it seems like a timing issue still exists:
I can probably play around with the window-size & sleep times below and get my tests to pass but I'm more concerned if there's a potential race condition/coordination step, outside of the MiniCluster test environment, that I should be dealing with.
My pipeline is broken into two parts: pipeA & pipeB. I've done this because the 2nd part has an async operator so it needs to be at the start of a chain. For a non-MiniCluster environment, would it be possible for records to flow through pipeA and not reach
pipeB, as I'm seeing with the MiniCluster? i.e. is there's something I need to do to explicitly connect/sync pipeA & pipeB before calling env.execute(), besides the fact that:
Thanks!
John.
public class StreamTest { From: Biao Liu <[hidden email]>
Sent: Tuesday 17 December 2019 21:50 To: John Morrow <[hidden email]> Cc: user <[hidden email]> Subject: Re: MiniCluster with ProcessingTimeTrigger Hi John,
The root cause is the collection source exits too fast. The window would also exit without being triggered.
You could verify that by waiting a second before releasing the window. For example, insert a map operator between source and window operator. Blocking a second or more in the "close" method of this map operator. You will see the window would work well.
Thanks,
Biao /'bɪ.aʊ/
On Wed, 18 Dec 2019 at 06:24, John Morrow <[hidden email]> wrote:
|
Hi John, The critical issue of your test case is that it's a finite streaming job. The mini cluster or distributed cluster does not matter. When the job is finishing, there are some windows not triggered yet. The current behavior is dropping these windows. It's acceptable from the perspective of window semantics. Because the condition (count/time based) is not fulfilled, the window should not be triggered. Normally we use window in infinite (or long running) streaming job. That means there should be rare scenarios of finishing or stopping. Even if the job is finished or stopped, the windows not triggered would also be dropped. BUT, they could be replayed if the job recovers from a checkpoint or savepoint. Let's get back to your test case. If you want the correct result, you have to fulfill the trigger condition of window. If the condition is processing time based with 2 seconds. You have to guarantee the window could run at-least 2 seconds. However it's not a good idea to design a time based test case. I would suggest to design the case in the way: the source would not exit until the window is triggered. The source could block on some signal (CountDownLatch?) which would be triggered after window has been triggered. Thanks, Biao /'bɪ.aʊ/ On Thu, 19 Dec 2019 at 06:06, John Morrow <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |