+1 for voting.
Best,
Jingsong
On Thu, Apr 6, 2023 at 4:52 PM yuxia wrote:
>
> Hi everyone.
>
> If there are no other questions or concerns for the FLIP[1], I'd like to
> start the vote next Monday (4.10).
>
> [1]
>
ZhengYi Weng created FLINK-31750:
Summary: Hash Keys are duplicate when join reorder happens in
stream mode
Key: FLINK-31750
URL: https://issues.apache.org/jira/browse/FLINK-31750
Project: Flink
junzhong qin created FLINK-31749:
Summary: The Using Hadoop OutputFormats example is not avaliable
for DataStream
Key: FLINK-31749
URL: https://issues.apache.org/jira/browse/FLINK-31749
Project:
Zili Chen created FLINK-31748:
-
Summary: Adapt SplitFetcherManager#removeSplit for
flink-connector-pulsar
Key: FLINK-31748
URL: https://issues.apache.org/jira/browse/FLINK-31748
Project: Flink
Mason Chen created FLINK-31747:
--
Summary: Externalize debezium from flink-json
Key: FLINK-31747
URL: https://issues.apache.org/jira/browse/FLINK-31747
Project: Flink
Issue Type: Improvement
Haoze Wu created FLINK-31746:
Summary: Batch workload output completes while the job client fails
Key: FLINK-31746
URL: https://issues.apache.org/jira/browse/FLINK-31746
Project: Flink
Issue
Do we have to move Debezium _now_?
There is no hard dependency between debezium-json and the Kafka
connector, nor does the format depend on Kafka afaict.
So is this only about the e2e test that uses debezium-json + kafka
connector?
If so, then I would suggest to put debezium-json issue aside
Hi Zakelly,
Thanks for driving this work!
I'm not sure did you ever read the discussion between Stephan, Roman, Piotr,
Yuan and I in the design doc [1] in nearly two years ago.
From my understanding, your proposal is also a mixed state ownership: some
states are owned by the TM while some are
Martijn Visser created FLINK-31745:
--
Summary: Performance regression on serializerHeavyString since
April 3rd
Key: FLINK-31745
URL: https://issues.apache.org/jira/browse/FLINK-31745
Project: Flink
Chesnay Schepler created FLINK-31744:
Summary: Extend Adaptive Scheduler sparse EG to contain
maxParallelism
Key: FLINK-31744
URL: https://issues.apache.org/jira/browse/FLINK-31744
Project: Flink
jinghaihang created FLINK-31743:
---
Summary: Avoid relocating the RocksDB's log failure when filename
exceeds 255 characters
Key: FLINK-31743
URL: https://issues.apache.org/jira/browse/FLINK-31743
Hi everyone.
If there are no other questions or concerns for the FLIP[1], I'd like to start
the vote next Monday (4.10).
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement
Best regards,
Yuxia
- 原始邮件 -
发件人: "yuxia"
收件人: "dev"
发送时间:
Hi Piotr,
Thanks for all the feedback.
(1) Thanks for the reminder. I have just seen the FLINK-24611, the delayed
deletion by JM resolves some sync problems between JM and TM, but I'm
afraid it is still not feasible for the file sharing in this FLIP.
Considering a concurrent checkpoint scenario
13 matches
Mail list logo