Great, thanks for clarifying!
Best,
Muhammet
On 2024-05-06 13:40, Ahmed Hamdy wrote:
Hi Muhammet,
Thanks for the feedback.
Could you please add more here why it is harder? Would the
`completeExceptionally`
method be related to it? Maybe you can add usage example for it also.
this is mainly due to the current implementation of fatal exception
failures which depends on base `getFatalExceptionConsumer` method that
is
decoupled from the actual called method `submitRequestEntries`, Since
this
is now not the primary concern of the FLIP, I have removed it from the
motivation so that the scope is defined around introducing the timeout
configuration.
Should we add a list of possible connectors that this FLIP would
improve?
Good call, I have added under migration plan.
Best Regards
Ahmed Hamdy
On Mon, 6 May 2024 at 08:49, Muhammet Orazov <mor+fl...@morazow.com>
wrote:
Hey Ahmed,
Thanks for the FLIP! +1 (non-binding)
> Additionally the current interface for passing fatal exceptions and
> retrying records relies on java consumers which makes it harder to
> understand.
Could you please add more here why it is harder? Would the
`completeExceptionally`
method be related to it? Maybe you can add usage example for it also.
> we should proceed by adding support in all supporting connector repos.
Should we add list of possible connectors that this FLIP would
improve?
Best,
Muhammet
On 2024-04-29 14:08, Ahmed Hamdy wrote:
> Hi all,
> I would like to start a discussion on FLIP-451[1]
> The proposal comes on encountering a couple of issues while working
> with
> implementers for Async Sink.
> The FLIP mainly proposes a new API similar to AsyncFunction and
> ResultFuture as well as introducing timeout handling for AsyncSink
> requests.
> The FLIP targets 1.20 with backward compatible changes and we should
> proceed by adding support in all supporting connector repos.
>
> 1-
>
https://cwiki.apache.org/confluence/display/FLINK/FLIP-451%3A+Refactor+Async+Sink+API
> Best Regards
> Ahmed Hamdy
