I'm still getting used to working with kafka, so I may have misunderstood the semantics, but it looks like seek-to-timestamp is handling the missing timestamp-offset case incorrectly: I don't think it should increment the end offset (see this line of client.clj).
FundingCircle/jackdaw#198 mentions being concerned about duplicate messages, but if I've understood correctly the endOffsets on a set of partitions are already past the most recent comitted message- the kafka javadocs state they correspond to the offset of the last committed message plus one (i.e. the offset that will be assigned the next message).
Similarly, I'm pretty sure that the test associated with this case should be looking for 10, not 11, since the final message of the test data has offset 9.
Could someone with more experience with kafka's semantics take a look?
I'm still getting used to working with kafka, so I may have misunderstood the semantics, but it looks like seek-to-timestamp is handling the missing timestamp-offset case incorrectly: I don't think it should increment the end offset (see this line of client.clj).
FundingCircle/jackdaw#198 mentions being concerned about duplicate messages, but if I've understood correctly the endOffsets on a set of partitions are already past the most recent comitted message- the kafka javadocs state they correspond to the offset of the last committed message plus one (i.e. the offset that will be assigned the next message).
Similarly, I'm pretty sure that the test associated with this case should be looking for 10, not 11, since the final message of the test data has offset 9.
Could someone with more experience with kafka's semantics take a look?