Suggested change to address the issue raised in #195
As the change to the test demonstrates, if the specified timestamp exceeds that of any previously written message, then rather than seek to the beginning of the partition, this change causes the consumer to seek to the end of the partition (and then increment by 1 to get the next message).
Points to note...
It might be safer not to increment and live with the risk of re-reading a single unwanted message rather than potentially skipping a message due to a race condition.
The call to .endOffsets seems like it might take a while (based on the fact that there is an arity that allows us to specify a timeout). One option to mitigate this is to use a deferred that only gets dereferenced if necessary. This ns doesn't yet depend on manifold though so I figured I'd leave it out for now and see if there are actual performance problems that warrant it.
The addition of (count topic-partitions) is not strictly necessary but is convenient for debugging. I introduced it because while stepping through the code in the debugger, I ran into this cider issue.
Suggested change to address the issue raised in #195
As the change to the test demonstrates, if the specified timestamp exceeds that of any previously written message, then rather than seek to the beginning of the partition, this change causes the consumer to seek to the end of the partition (and then increment by 1 to get the next message).
Points to note...
.endOffsetsseems like it might take a while (based on the fact that there is an arity that allows us to specify a timeout). One option to mitigate this is to use a deferred that only gets dereferenced if necessary. This ns doesn't yet depend on manifold though so I figured I'd leave it out for now and see if there are actual performance problems that warrant it.(count topic-partitions)is not strictly necessary but is convenient for debugging. I introduced it because while stepping through the code in the debugger, I ran into this cider issue.