Re: [DISCUSS] Change underlying Frontend Architecture for Flink Web Dashboard

Hi Yadong, this is awesome, thx for the code! I will try it out on our infrastructure and will post my feedback here, latest next week. I will also check if my ideas for FLINK-10707 are doable with your code since this was what pushed this discus

Re: [DISCUSS] Change underlying Frontend Architecture for Flink Web Dashboard

Hi Fabian, Till, and Robert Thank you for your attention to this matter, I just push our codes to github: https://github.com/vthinkxie/flink-runtime-web. You can start the project by following the guidelines (just run `npm in

Re: [DISCUSS] Flink SQL DDL Design

Hi, Shuyi, thanks for the proposal. I have two concerns about the table ddl: 1. how about remove the source/sink mark from the ddl, because it is not necessary, the framework determine the table referred is a source or a sink according to the context of the query using the table. it will be more

Re: [DISCUSS] FLIP-27: Refactor Source Interface

Hi Thomas, The iterator-like API was also the first thing that came to me. But it seems a little confusing that hasNext() does not mean "the stream has not ended", but means "the next record is ready", which is repurposing the well known meaning of hasNext(). If we follow the hasNext()/next() patt

Re: [DISCUSS] Enhancing the functionality and productivity of Table API

Hi Jincheng, Thank you for the proposal! I think being able to define a process / co-process function in table API definitely opens up a whole new level of applications using a unified API. In addition, as Tzu-Li and Hequn have mentioned, the benefit of optimization layer of Table API will alread

Re: [DISCUSS] Enhancing the functionality and productivity of Table API

Hi tison, Thanks a lot for your feedback! I am very happy to see that community contributors agree to enhanced the TableAPI. This work is a long-term continuous work, we will push it in stages, we will soon complete the enhanced list of the first phase， we can go deep discussion in google doc. t

Re: [DISCUSS] FLIP-27: Refactor Source Interface

Couple more points regarding discovery: The proposal mentions that discovery could be outside the execution graph. Today, discovered partitions/shards are checkpointed. I believe that will also need to be the case in the future, even when discovery and reading are split between different tasks. F

Re: [DISCUSS] FLIP-27: Refactor Source Interface

Thanks for getting the ball rolling on this! Can the number of splits decrease? Yes, splits can be closed and go away. An example would be a shard merge in Kinesis (2 existing shards will be closed and replaced with a new shard). Regarding advance/poll/take: IMO the least restrictive approach wou

[jira] [Created] (FLINK-10774) connection leak when partition discovery is disabled and open throws exception

Steven Zhen Wu created FLINK-10774: -- Summary: connection leak when partition discovery is disabled and open throws exception Key: FLINK-10774 URL: https://issues.apache.org/jira/browse/FLINK-10774 Pr

[jira] [Created] (FLINK-10773) Resume externalized checkpoint end-to-end test fails

Till Rohrmann created FLINK-10773: - Summary: Resume externalized checkpoint end-to-end test fails Key: FLINK-10773 URL: https://issues.apache.org/jira/browse/FLINK-10773 Project: Flink Issue

[jira] [Created] (FLINK-10772) create_binary_release.sh is broken

Till Rohrmann created FLINK-10772: - Summary: create_binary_release.sh is broken Key: FLINK-10772 URL: https://issues.apache.org/jira/browse/FLINK-10772 Project: Flink Issue Type: Bug

Re: [DISCUSS] FLIP-27: Refactor Source Interface

Hi, Thanks Aljoscha for this FLIP. 1. I agree with Piotr and Becket that the non-blocking source is very important. But in addition to `Future/poll`, there may be another way to achieve this. I think it may be not very memory friendly if every advance call return a Future. public interface Listen

[jira] [Created] (FLINK-10771) Replace hard code of job graph file path with config option for FileJobGraphRetriever

vinoyang created FLINK-10771: Summary: Replace hard code of job graph file path with config option for FileJobGraphRetriever Key: FLINK-10771 URL: https://issues.apache.org/jira/browse/FLINK-10771 Project

Re: [DISCUSS] Flink SQL DDL Design

+1, Thanks for the proposal. I guess this is a long-awaited change. This can vastly increase the functionalities of the SQL Client as it will be possible to use complex extensions like for example those provided by Apache Bahir[1]. Best Regards, Dom. [1] https://github.com/apache/bahir-flink s