Hello Greg,
Sorry for the long delay in responses, but very glad to see you have gone
this far to resolve the problem. All of your solutions make sense to me.
I think for the first problem your raised, it is a general problem not only
for Streams' sending changelog records but for any clients tha
After more digging, a good solution seems to be to set the topic timetstamp
policy to LogAppendTime and also update our timestamp extractor to respect
this (by just returning record.timestamp() if the timestamp type is set to
LogAppendTime.) This gets us the semantics we want for the changelog topi
I managed to answer some of my own questions :)
For future google'ers:
to deal with retention.ms see
https://issues.apache.org/jira/browse/KAFKA-4340
to deal with early rejection of bad timestamps the
message.timestamp.difference.max.ms config is relevant discussion here
https://issues.apache.org
