You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
#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?
The text was updated successfully, but these errors were encountered:
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).
#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?
The text was updated successfully, but these errors were encountered: