Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[FLINK-13248] [runtime] Adding processing of downstream messages for blocking operators #9383
What is the purpose of the change
Brief change log
Verifying this change
Does this pull request potentially affect one of the following parts:
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
Last check on commit 8dca786 (Fri Sep 06 09:07:59 UTC 2019)
Mention the bot in a comment to re-run the automated checks.
Please see the Pull Request Review Guide for a full explanation of the review process.
The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required
The @flinkbot bot supports the following commands:
6 times, most recently
Aug 14, 2019
1u0 left a comment
You are removing the
Initially, this functionality was added for convenience to have futures that result with a mailbox letter.
1u0 left a comment •
Implementation wise, it looks like the main (task level) mailbox (
Instead, I think, it still could be a proper mailbox that can allow executing any letters. In particular, some timer triggers and checkpoints are operator neutral. They still could progress independently of operators.
Yes, MAX_INT makes more sense than 0 in any case. That was actually my original intent.
The basic idea of removing the ExecutorService interface is to get rid of the life-cycle methods. Since each Mailbox view is wrapped into an MailboxExecutor, each Mailbox view would also need to have life-cycle methods, which is a total mess.
Instead, we just support the Executor interface, which is enough to support the nice CompletableFuture usages.
After some discussions, we moved it to -1 instead and just treat priority mail with MAX_INT.
pnowojski left a comment •
Code LGTM. I think one last minor comment about commit's structure.
Besides that commit names are a bit confusing I think:
this is not a
I think it is also a bit confusing, as it doesn't reference yield to downstream/priorities. Also this one deservers more description in the commit message. What do you think about something along those lines:
Optionally I would expand the commit description of the commit that's exposing