- 28 12月, 2020 5 次提交
-
-
由 vthinkxie 提交于
-
由 huangxingbo 提交于
[FLINK-20756][python] Fix the bug that it doesn't support field access of expression containing Python UDF in the condition of Calc This closes #14492.
-
由 kougazhang 提交于
This closes #14362 Co-authored-by: Nzhao.zhang <zhao.zhang@upai.com>
-
由 huangxingbo 提交于
[FLINK-20620][table-planner-blink][python] Port BatchExecPythonCalc and StreamExecPythonCalc to Java This closes #14496.
-
由 huangxingbo 提交于
[FLINK-20712][python] Support join_lateral/left_outer_join_lateral to accept table function directly This closes #14500.
-
- 27 12月, 2020 2 次提交
-
-
由 Kezhu Wang 提交于
[FLINK-20657][connectors/jdbc] Migrate jdbc InputFormat/LookupFunction to SimpleJdbcConnectionProvider for connection establishment This closes #14466
-
由 Shengkai 提交于
This closes #13800
-
- 25 12月, 2020 13 次提交
-
-
由 龙三 提交于
[FLINK-20736][table-planner-blink] Introduce StreamPhysicalRank & StreamPhysicalLimit, and make StreamExecRank & StreamExeLimit only extended from ExecNode This closes #14472
-
由 龙三 提交于
[FLINK-20736][table-planner-blink] Introduce BatchPhysicalLimit, and make BatchExecLimit only extended from ExecNode This closes #14472
-
由 godfreyhe 提交于
[FLINK-20706][table-planner-blink] Introduce BatchPhysicalUnion, and make BatchExecUnion only extended from ExecNode This closes #14455
-
由 godfreyhe 提交于
[FLINK-20706][table-planner-blink] Introduce StreamPhysicalUnion, and make StreamExecUnion only extended from ExecNode This closes #14455
-
由 huangxingbo 提交于
This closes #14473.
-
由 Aljoscha Krettek 提交于
This closes #14489
-
由 wangyang0918 提交于
This closes #14447
-
由 blublinsky 提交于
-
由 huangxingbo 提交于
This closes #14487.
-
由 Jack 提交于
This closes #14452
-
由 肖佳文 提交于
This closes #14387
-
由 meijie 提交于
This closes #14387
-
由 wangyang0918 提交于
This closes #14486
-
- 24 12月, 2020 13 次提交
-
-
由 Jark Wu 提交于
-
由 Qingsheng Ren 提交于
This closes #13876
-
由 godfrey he 提交于
[FLINK-20709][table-planner-blink] Introduce StreamPhysicalMiniBatchAssigner, and make StreamExecMiniBatchAssigner only extended from ExecNode This closes #14459
-
由 godfrey he 提交于
[FLINK-20708][table-planner-blink] Introduce StreamPhysicalDropUpdateBefore, and make StreamExecDropUpdateBefore only extended from ExecNode This closes #14458
-
由 godfreyhe 提交于
[FLINK-20707][table-planner-blink] Introduce BatchPhysicalExpand, and make BatchExecExpand only extended from ExecNode This closes #14457
-
由 godfreyhe 提交于
[FLINK-20707][table-planner-blink] Introduce StreamPhysicalExpand, and make StreamExecExpand only extended from ExecNode This closes #14457
-
由 godfreyhe 提交于
[FLINK-20705][table-planner-blink] Introduce BatchPhysicalValues, and make BatchExecValues only extended from ExecNode This closes #14454
-
由 godfreyhe 提交于
[FLINK-20705][table-planner-blink] Introduce StreamPhysicalValues, and make StreamExecValues only extended from ExecNode This closes #14454
-
由 Jingsong Lee 提交于
This closes #14474
-
由 Zhu Zhu 提交于
[FLINK-20439][runtime] Rename `scheduleOrUpdateConsumers` to `notifyPartitionDataAvailable` to avoid confusion
-
由 Zhu Zhu 提交于
notifyPartitionDataAvailable() is introduced to replace scheduleOrUpdateConsumers() in the RPC code path. Execution#scheduleOrUpdateConsumers is renamed to #updatePartitionConsumers to be aligned with what id does.
-
由 Chesnay Schepler 提交于
-
由 Chesnay Schepler 提交于
-
- 23 12月, 2020 7 次提交
-
-
由 HuangXingBo 提交于
-
由 huangxingbo 提交于
This closes #14449.
-
由 Till Rohrmann 提交于
This is a safety net which ensures that the JobManagerRunnerImpl will fail if the JobMasterService fails unexpectedly. This closes #14432.
-
由 Chesnay Schepler 提交于
When a slot was freed the slot pool was trying to find another requirement it could potentially fulfill, using the same code paths as for newly offered slots, which also includes an increase in acquired resources. As a result we were potentially counting a single slot as multiple resources, causing an inconsistent state. The slot pool hence believed it had enough slots to fulfill the requirements, causing it to reject slots, while the Scheduler was waiting for enough slots to arrive and the RM repeatedly trying to provide the actually required slots. While it is not necessarily a bad thing to try an find another matching requirement, it is currently not necessary to do so, since the scheduler will use slots however it sees fit anyway. In the worst case we go through another slot allocation cycle. As such freed slots now remain assigned to the originally matched requirement, and this mapping will only change whe the slot is explicitly reserved for a different requirement. In the long-term it would be desirable for the slot pool to automatically adjust the matching if a slot was freed. This could prevent cases where we request new slots although we still have idling slots around that we could use, or release slots as idle although there are still outstanding requirements. However this needs a more sophisticated approach, it has to account for cases where: - a freed slot could not be matched to another requirement (i.e., it is truly an excess resource) - a freed slot was matched against another profile, which should go through the same codepath as for slot reservations for a different profile - also try to re-assign currently excess resources if the requirements are increased
-
由 Chesnay Schepler 提交于
- log total acquired resources when declaring requirements, or after accepting new / releasing idle slots - log if an offer could not be matched to any requirement
-
由 Chesnay Schepler 提交于
There are multiple events where resource requirements might not actually change, and so far the user of the slot pool was responsible for checking that the requirements have actually changed to prevent unnecessary RPC calls. Since this is something that every user should check, we might as well always do this automatically.
-
由 Chesnay Schepler 提交于
-