I hadn't considered the case for specifying a
read-behind. I could see how it'd be useful when say the
retention period on the topic itself may be a couple of days but
you'd want to read behind maybe just an hour or so to prime the
cache and then get anything new that comes in after that. I
could also see going back a specific number of messages being
convenient when either the timespan of the data is long (e.g.:
for low volume data) or the user might just want to prime the
cache based on the last x messages. Allowing for the combo of
those settings is another route to go down where the read behind
will start at the offset which was found at the point where
either of the criteria was first met.
If you create a JIRA ticket for the auto.offset.reset task,
I can work on that feature initially and create a pull
request. For the time and/or count based read behind feature
you described, I'd need to find some more concrete use cases
that require a specific look behind config before going down
that route but, I definitely agree that it'd be a better long
term solution to allow for that level of flexibility.
