jackdaw

https://github.com/FundingCircle/jackdaw
2019-09-17T11:32:47.011400Z

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.

2019-09-17T11:36:23.014100Z

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.

2019-09-17T12:20:26.015600Z

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

2019-09-17T12:23:52.016500Z

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.

2019-09-17T12:38:33.019600Z

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.