Great all of that sounds good to me.
Since we are all in agreement, we can move to a vote.
-Bill
On Wed, Jan 15, 2020 at 11:51 AM am <jbfle...@happypants.org> wrote:
> I agree WARN seems like it would be fine given we already log at that
> level for the handler. It also seems reasonable to exclude the
> ClassCastException as that can indicate something other then a simple
> serialization exception and would keep the current behavior.
>
> anna
>
> On Tue, Jan 14, 2020 at 11:41 PM Matthias J. Sax <matth...@confluent.io>
> wrote:
> >
> > I was just checking the existing code, and we currently log at WARN
> > level if the handler returns CONTINUE -- we did not have any complaints
> > about it, hence, I don't see an issue with WARN -- and we should keep it
> > consistent.
> >
> > I think the explicit mentioning of `ClassCastException` is based on the
> > current code that catches this exception to rethrow it -- this was a
> > minor improvement to help people to more easily detect miss-configure
> > serdes.
> >
> > In think, we can just catch all exception and the handler can decide
> > what to do. Thinking about this once more, it might actually be better
> > if we could _exclude_ `ClassCastException` as it may indicate a miss
> > configured Serde?
> >
> >
> > -Matthias
> >
> > On 1/14/20 4:15 PM, Bill Bejeck wrote:
> > > Hi Anna,
> > >
> > > Thanks for getting this KIP going again.
> > >
> > > I agree with pushing forward on option 0 as well. I a couple of
> questions
> > > about the KIP as written.
> > >
> > > The KIP states that any {{ClassCastException}} thrown plus any other
> > > unchecked exceptions will result in a log statement and not stop
> processing
> > > if the handler returns CONTINUE.
> > >
> > > 1. I'm wondering if DEBUG is the correct level vs. a WARN,
> although, at
> > > WARN, we could end up spamming the log file.
> > > 2. Are allowing all unchecked exceptions to proceed to permissive?
> I
> > > could be overly cautious here, but I'm afraid of masking a serious
> > > problem.
> > >
> > > Overall I'm in favor of this KIP and if you feel it's good as is, I
> > > wouldn't block on these questions I just wanted to throw in my 2
> cents.
> > >
> > > Thanks,
> > > Bill
> > >
> > > On Sat, Jan 11, 2020 at 7:02 PM Mitchell <mitche...@gmail.com> wrote:
> > >
> > >> I'm happy to have the serialization handler now. I've hit this issue
> > >> a number of times in the past.
> > >>
> > >> I think the other options are also large enough they probably deserve
> > >> their own KIPs to properly document the changes.
> > >> -mitch
> > >>
> > >> On Fri, Jan 10, 2020 at 7:33 PM am <jbfle...@happypants.org> wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>> I would like to re-restart the discussion of KIP-399
> > >>>
> > >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-399%3A+Extend+ProductionExceptionHandler+to+cover+serialization+exceptions
> > >>>
> > >>> The last conversation centered on if this KIP should address the
> issues
> > >>> around state store/change log divergence with Matthias presenting
> three
> > >>> options:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> *To move this KIP forward, maybe we can just (0) add the handler
> > >>> forserialization exceptions when writing into any topic and consider
> it
> > >>> anincremental improvement. Ie, (1) we keep the door open to let state
> > >>> andchangelog topic diverge (current status) (2) we allow people to
> > >>> violateEOS (current state) (3) and we don't improve the handling of
> DSL
> > >>> statestore serialization exceptions.We could address (1), (2),
> and/or (3)
> > >>> in follow up KIPs.Thoughts? Let us know if you only want to address
> (0),
> > >> or
> > >>> extend thecurrent KIP to include any of (1-3).*
> > >>>
> > >>>
> > >>> I would like to propose we go with option 0 and treat this as an
> > >>> incremental improvement that applies to any topic and address the
> issue
> > >> of
> > >>> divergence in future KIP(s).
> > >>>
> > >>> Feedback, thoughts and musings appreciated,
> > >>>
> > >>> anna
> > >>
> > >
> >
>
