Fork me on GitHub
#jackdaw
<
2019-09-17
>
cddr11:09:47

We have talked internally about migrating to deps. Most people seem generally in favor but there hasn't been anything that has forced the issue yet for us.

cddr11:09:23

re: https://github.com/FundingCircle/jackdaw/issues/195 I'm sorry you're finding all the little-used parts of the code-base. Most of it seems to work for us but I must admit that both topics-ready? and seek-to-timestamp are not actually used in any of the code-bases that I work on myself. I'm 👀 at it now and checking against the javadocs to come up with an answer.

cddr12:09:26

Hey Josip, I looked into this a bit. The problem is that the upstream API call .offsetsForTimes returns null when the timestamp exceeds that of any message in the partition. But it also always returns null if the broker happens to be old enough to not support timestamps. Currently when it returns null, we set the offset to 0. If the broker was known to be one which supported timestamps, it might be better to set the offset to the latest value as advertised in the doc string. Would be nice if the upstream API would distinguish between these cases. I'll have a quick look in their jira to see if anyone has noticed this and reported something

cddr12:09:52

Ah actually, maybe we can rely on https://issues.apache.org/jira/browse/KAFKA-5534 to indicate that nothing has been found and we can use the latest offset instead.

Josip Gracin12:09:33

Andy, thanks for your time and effort! I find the code to be of very high quality and I'm glad I can help in finding these corner cases in rarely used APIs. I'll check the Kafka issue that you mention.