Yuan Mei created FLINK-24435:
Summary: FsStateChangelogWriter#lastAppendedSequenceNumber return
different seq number with no writes
Key: FLINK-24435
URL: https://issues.apache.org/jira/browse/FLINK-24435
Yuan Mei created FLINK-24436:
Summary: FsStateChangelogWriter#lastAppendedSequenceNumber return
different seq number with no writes
Key: FLINK-24436
URL: https://issues.apache.org/jira/browse/FLINK-24436
Hi all,
Nice thread and great discussion! Ecosystem is one of the most important
things
to the Flink community, we should pay more attention to API compatibility.
Marking all connector APIs @Public is a good idea, not only mark the
Table/SQL
connector APIs public, but also the new Source/Sink API
Till Rohrmann created FLINK-24437:
-
Summary: Remove unhandled exception handler from CuratorFramework
before closing it
Key: FLINK-24437
URL: https://issues.apache.org/jira/browse/FLINK-24437
Project:
Hi,
> [...] but also the new Source/Sink APIs as public
I'm not really involved in the new Source/Sink APIs and will happily listen
to the developers working with them here, but since they are new, we should
also be careful not to mark them as stable too quickly. We've only begun
updating the exi
Hi all,
Thanks a lot for your feedback guys ! Special thanks to Fabian, Till and
Arvid (in a private discussion) !
The consensus seems to go toward the blog post on migrating a batch
pipeline from DataSet API to DataStream API. For the record it is linked
to a work I did lately (unfortunatel
Martijn Visser created FLINK-24438:
--
Summary: Port Kinesis Source to new Source API (FLIP-27)
Key: FLINK-24438
URL: https://issues.apache.org/jira/browse/FLINK-24438
Project: Flink
Issue Typ
The issue is that if we do not mark them as Public, we will always have
incompatibilities. The change of SourceReaderContext#metricGroup is
perfectly fine according to the annotation. The implications that we see
here just mean that the interfaces have been expected to be Public.
And now the quest
Hi Arvid,
> Should we expect connector devs to release different connector binaries
for different Flink minors?
>From the discussion of this thread, I think the answer is obviously "not",
otherwise OpenInx won't start
this discussion. As a maintainer of flink-cdc-connector, I have to say
that it'
Piotr Nowojski created FLINK-24440:
--
Summary: Announce and combine latest watermarks across
SourceReaders
Key: FLINK-24440
URL: https://issues.apache.org/jira/browse/FLINK-24440
Project: Flink
Piotr Nowojski created FLINK-24441:
--
Summary: Block SourceReader when watermarks are out of alignment
Key: FLINK-24441
URL: https://issues.apache.org/jira/browse/FLINK-24441
Project: Flink
I
Piotr Nowojski created FLINK-24439:
--
Summary: Introduce a CoordinatorStore
Key: FLINK-24439
URL: https://issues.apache.org/jira/browse/FLINK-24439
Project: Flink
Issue Type: Sub-task
Hi,
I don't understand why we are talking about this being a blocker issue? New
sources were not marked as @Public for a good reason until 1.14. I agree,
we should try better at making APIs @Public sooner. I was even proposing to
create strict timeout rules (enforced via some automated checks) lik
13 matches
Mail list logo
