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 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 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 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
> >>
> >
>
