Surendra Singh Lilhore created FLINK-34565:
--
Summary: Enhance flink kubernetes configMap to accommodate
additional configuration files
Key: FLINK-34565
URL:
RocMarshal created FLINK-34564:
--
Summary: Unstable test case
TableSourceITCase#testTableHintWithLogicalTableScanReuse
Key: FLINK-34564
URL: https://issues.apache.org/jira/browse/FLINK-34564
Project:
Hi,
Thanks for the great proposals. I have a few comments comments:
- Backpressure Handling. Flink's original backpressure handling is quite
robust and the semantics is quite "simple" (simple is beautiful).
This mechanism has proven to perform better/robust than the other open
source streaming
Yang LI created FLINK-34563:
---
Summary: Autoscaling decision improvement
Key: FLINK-34563
URL: https://issues.apache.org/jira/browse/FLINK-34563
Project: Flink
Issue Type: Improvement
Thanks Piotr for sharing your thoughts!
I guess it depends how we would like to treat the local disks. I've always
> thought about them that almost always eventually all state from the DFS
> should end up cached in the local disks.
OK I got it. In our proposal we treat local disk as an optional
Lorenzo Affetti created FLINK-34562:
---
Summary: Port Debezium Avro Confluent changes (FLINK-34509) to
Chinese
Key: FLINK-34562
URL: https://issues.apache.org/jira/browse/FLINK-34562
Project: Flink
Hi,
According to the current standards I created a Google doc for the FLIP [1]. I
pointed it to the this discussion but if a dedicated discussion should be
started for it, pls. let me know. PTAL.
Regards,
Ferenc
[1]
Good day,
As we approach the season of ASF events, we are seeking assistance from
some Apache PMC committers to discover contact information for the various
organizations that use and contribute to those projects, in the hopes of
partnering with them on event sponsorship. This will help make
Avi Sanwal created FLINK-34561:
--
Summary: Downgrading flink-kubernetes-operator causes failure
Key: FLINK-34561
URL: https://issues.apache.org/jira/browse/FLINK-34561
Project: Flink
Issue Type:
Hi,
Thanks for proposing this design! I just read FLIP-424 and FLIP-425
and have some questions about the proposed changes.
For Async API (FLIP-424)
1. Why do we need a close() method on StateIterator? This method seems
unused in the usage example codes.
2. In FutureUtils.combineAll()'s
Matthias Pohl created FLINK-34560:
-
Summary: JoinITCase seems to fail on a broader scale (MiniCluster
issue?)
Key: FLINK-34560
URL: https://issues.apache.org/jira/browse/FLINK-34560
Project: Flink
Thanks for your answers Zakelly. I get your points.
> (...) it may not be suitable for scenarios where
> - A state is read by condition.
> - MapState with the user key cannot be determined in advance.
I guess it depends how we would like to treat the local disks. I've always
thought about them
Roman Khachatryan created FLINK-34559:
-
Summary: TVF Window Aggregations might stuck
Key: FLINK-34559
URL: https://issues.apache.org/jira/browse/FLINK-34559
Project: Flink
Issue Type:
Jufang He created FLINK-34558:
-
Summary: Add RocksDB key/value size metrics
Key: FLINK-34558
URL: https://issues.apache.org/jira/browse/FLINK-34558
Project: Flink
Issue Type: Improvement
tanliang created FLINK-34557:
Summary: When the Flink task ends in application mode, there may
be issues with the Znode and HDFS files not being deleted
Key: FLINK-34557
URL:
15 matches
Mail list logo