Hi Mickael,
Thanks for your comments.
I've added a use case into the KIP, and added Boyang's comment into
rejected alternatives section.
Hope that makes sense and strengthens the motivation.
If you have other suggestions, please let me know.
Thank you.
Luke
On Mon, Oct 4, 2021 at 10:23 PM
Hi Luke,
Thanks for the KIP.
Can you clarify the use cases you have in mind exactly? This would
strengthen the motivation which I find a bit weak at the moment.
As mentioned by Boyang, it's possible to achieve something similar
with the existing APIs, for example with poll/seek or with
Thanks for your feedback, Sagar, Boyang.
I've added an additional API to take the Set as the
partitions to fetch from. Good suggestion!
I also updated the java doc in the KIP.
And for the question that the behavior can also be achieved by using manual
offset commit + offset position rewind.
Thanks Luke for the KIP. I think it makes sense.
@Boyang,
While it is possible to get the functionality using manual offset commit +
offset position rewind as you stated, IMHO it could still be a very handy
addition to the APIs. The way I see it, manual offset commit + offset
position rewind is
Thanks Luke for the KIP.
I think I understand the motivation is to avoid affecting offset positions
of the records, but the feature could be easily realized on the user side
by using manual offset commit + offset position rewind. So the new peek()
function doesn't provide any new functionality
Hi everyone,
I'd like to discuss the following proposal to add Consumer#peek for
debugging/tuning.
The main purpose for Consumer#peek is to allow users:
1. peek what records existed at broker side and not increasing the
position offsets.
2. throw exceptions when there is connection
