flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-5701) FlinkKafkaProducer should check asyncException on checkpoints
Date Mon, 06 Feb 2017 17:24:41 GMT

    [ https://issues.apache.org/jira/browse/FLINK-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854409#comment-15854409

ASF GitHub Bot commented on FLINK-5701:

Github user tzulitai commented on the issue:

    Yes, in the condition that you described, then at-least-once doesn't hold. I said _might_
mainly considering there is chance that for every checkpoint barrier, the previous events
(i.e. `event1` in your example) has been committed. But yes, essentially this indeterminate
behaviour means that it is not at-least-once, so I'm incorrect in saying that it _might_.
    I was trying to point out that this indeterminate behaviour made it hard to have a stable
test for `testAtLeastOnceProducerFailsIfFlushingDisabled()` without relying on sleeping, which
ultimately leads to flaky tests.

> FlinkKafkaProducer should check asyncException on checkpoints
> -------------------------------------------------------------
>                 Key: FLINK-5701
>                 URL: https://issues.apache.org/jira/browse/FLINK-5701
>             Project: Flink
>          Issue Type: Bug
>          Components: Kafka Connector, Streaming Connectors
>            Reporter: Tzu-Li (Gordon) Tai
>            Priority: Critical
> Reported in ML: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Fink-KafkaProducer-Data-Loss-td11413.html
> The problem:
> The producer holds a {{pendingRecords}} value that is incremented on each invoke() and
decremented on each callback, used to check if the producer needs to sync on pending callbacks
on checkpoints.
> On each checkpoint, we should only consider the checkpoint succeeded iff after flushing
the {{pendingRecords == 0}} and {{asyncException == null}} (currently, we’re only checking
> A quick fix for this is to check and rethrow async exceptions in the {{snapshotState}}
method both before and after flushing and {{pendingRecords}} becomes 0.

This message was sent by Atlassian JIRA

View raw message