With
props.put(StreamsConfig.DEFAULT_DESERIALIZATION_EXCEPTION_HANDLER_CLASS_CONFIG,
LogAndContinueExceptionHandler.class);
Scenario A:
Run application. Feed a message into the topic that will fail deserialization.
Application logs exception and keeps running.
Shut down application. Restart application.
Application re-reads broken message, logs exception again (and keeps running).
Scenario B:
Run application. Feed a message into the topic that will fail deserialization.
Application logs exception and keeps running.
Feed a good message into deserialization.
Application processes it normally.
Shut down application. Restart application.
Application does *not* re-reads broken message.
So it looks like LogAndContinueExceptionHandler does not seem to commit() the
incoming "poison pill" message(s), and these will be re-read if the application
is restarted without any good messages having been read after the bad ones.
Have I understood this correctly? If so, is this correct behaviour as designed?
Is it documented to that level of detail?
Tim Ward
The contents of this email and any attachment are confidential to the intended
recipient(s). If you are not an intended recipient: (i) do not use, disclose,
distribute, copy or publish this email or its contents; (ii) please contact the
sender immediately; and (iii) delete this email. Our privacy policy is
available here: https://origamienergy.com/privacy-policy/. Origami Energy
Limited (company number 8619644); Origami Storage Limited (company number
10436515) and OSSPV001 Limited (company number 10933403), each registered in
England and each with a registered office at: Ashcombe Court, Woolsack Way,
Godalming, GU7 1LQ.
