Hello Pushkar,

I'd split records/events in categories based on the error:
- Events that can be parsed or otherwise handled correctly, e.g. good events
- Fatal error, like parsing error, empty or incorrect values, etc., e.g. bad 
events
- Non-fatal, like database-connection failure, io-failure, out of memory, and 
others
  that could be retried

Best to avoid doing something blocking while handling the error, so create a 
separate stream for each. That way 'good' events don't have to wait for the 
handling of 'bad' events.

Any fatal can events you could store in a separate topic, or send to some 
monitoring/logging system. As a simple start you could sent the erroneous 
events to a separate topic named something like 'errorevents'. 
Any non-fatal errors could be retried. Last time I used Akka for that 
(https://doc.akka.io/docs/alpakka-kafka/current/errorhandling.html) but afaik 
KStreams has mechanism for that as well.  You could also store records that you 
want to retry into a separate topic 'retry'.
Do not store records that that you want to retry back into the original topic! 
If you do that you're have a great risk that overload you're whole 
kafka-cluster.

Op 18-06-2020 09:55 heeft Pushkar Deole <pdeole2...@gmail.com> geschreven:

    Hi All,

    This is what I am observing: we have a consumer which polls data from
    topic, does the processing, again polls data which keeps happening
    continuously.
    At one time, there was some bad data on the topic which could not be
    consumed by consumer, probably because it couldn't deserialize the event
    due to incompatible avro schema or something similar,
    and consumer got error deserializing event. Since the exception wasn't
    handled, it crashed the consumer thread which then stopped consuming data.

    The question here is how these kind of scenarios can be handled:
    1. Even if I catch the exception and log it, the consumer will i think
    process the next event. So the bad event will be lost
    2. When consumer goes for another poll, it would commit offsets of previous
    poll which includes bad event, So the event will be lost

    How can this scenario be handled in best possible way?

Reply via email to