t;
>>> yungao...@aliyun.com>:
>>>
>>>> Hi nick,
>>>>
>>>>Sorry I initially think that the data is also write into Kafka with
>>>> flink . So it could be ensured that there is no delay in the write side,
>>>> rig
>>> Yun
>>>
>>>
>>>
>>> --Original Mail --
>>> *Sender:*nick toker
>>> *Send Date:*Tue Dec 22 01:43:50 2020
>>> *Recipients:*Yun Gao
>>> *CC:*user
>>> *Subject:*Re: checkpoint delay
write side,
>> right ? Does the delay in the read side keeps existing ?
>>
>> Best,
>> Yun
>>
>>
>>
>> --Original Mail ------
>> *Sender:*nick toker
>> *Send Date:*Tue Dec 22 01:43:50 2020
>> *Recipients:*Yun
delay in the write side,
> right ? Does the delay in the read side keeps existing ?
>
> Best,
> Yun
>
>
>
> --Original Mail --
> *Sender:*nick toker
> *Send Date:*Tue Dec 22 01:43:50 2020
> *Recipients:*Yun Gao
> *CC:*user
> *Su
Hi nick,
Sorry I initially think that the data is also write into Kafka with flink .
So it could be ensured that there is no delay in the write side, right ? Does
the delay in the read side keeps existing ?
Best,
Yun
--Original Mail --
Sender:nick toker
hi
i am confused
the delay in in the source when reading message not on the sink
nick
בתאריך יום ב׳, 21 בדצמ׳ 2020 ב-18:12 מאת Yun Gao <yungao...@aliyun.com
>:
> Hi Nick,
>
> Are you using EXACTLY_ONCE semantics ? If so the sink would use
> transactions, and only commit the transa
Hi Nick,
Are you using EXACTLY_ONCE semantics ? If so the sink would use
transactions, and only commit the transaction on checkpoint complete to ensure
end-to-end exactly-once. A detailed description could be find in [1]
Best,
Yun
[1]
https://flink.apache.org/features/2018/03/01/end-t
