Hi David,
Thanks for your response.
The exceptions thrown by state interfaces are NOT retriable. For
example, there may be some elements sent to the wrong subtask due to a
non-deterministic hashCode() algorithm and the key group is not
matching. Or the rocksdb may fail to read a file if it has be
Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
thrown in state interfaces
Hi David,
Thanks for your response.
The exceptions thrown by state interfaces are NOT retriable. For
example, there may be some elements sent to the wrong subtask due to a
non-deterministic hashCode
To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the
> exceptions thrown in state interfaces
> Hi David,
>
> Thanks for your response.
>
> The exceptions thrown by state interfaces are NOT retriable. For
> example, there may be some el
hould not be trying to create code now for an implementation
> > consideration that is not there yet,
> >
> > +1 from me ,
> > Kind regards, David.
> >
> > From: Zakelly Lan
> > Date: Wednesday, 11 October 2023 at 04:25
> > To: dev@flink.apache.org
&
t you make about if there are future
> > > implementations that are
> > > worth retrying (such as network access) – then there could be retries.
> I
> > > agree we should not be trying to create code now for an implementation
> > > consideration that is not t
Date: Friday, 13 October 2023 at 14:30
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
thrown in state interfaces
HI Zakelly,
What about the jobs that catch those exceptions? Will these downstream
callers that expect this exception to be
m: Jing Ge
> Date: Friday, 13 October 2023 at 14:30
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
> thrown in state interfaces
> HI Zakelly,
>
> What about the jobs that catch those exceptions? Will these downstream
&
On balance, as I am risk averse, I would suggest delaying this to v2 as
> Jing has proposed. This is a cleaner API, is there a demand for this in a
> dot version? If the community think this is too risk averse, then we could
> go with 1.19.
> > WDYT?
> >
> > Kind regard
gt; > >
> > > > > But "Since the signature of the public state API has been changed",
> > I was
> > > > > wondering whether this would be more fittable in Flink 2.0, instead
> > of
> > > > 1.19?
> > > >