[
https://issues.apache.org/jira/browse/KAFKA-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708475#comment-14708475
]
Jay Kreps commented on KAFKA-2390:
----------------------------------
Guys, this seems like a cure that is worse than the disease.
Here is what tends to happen in API design that I'm seeing here: complexity
gets added to the interface that effects all users but only helps very low
probability uses. The complexity makes all users worse off while only improving
life for a very small percentage of users. The result is a very complicated api
that sucks at the common cases. Good APIs require everyone to emphasize
simplicity and react strongly to attempts to lard up the api with complexity
unless it is absolutely necessary.
The intended usage for the API is the following:
1. If you want the consumer to automatically recover you set the offset reset
policy to latest/earliest
2. If you want to manage things yourself you set the offset reset policy to
none and catch the exception and do whatever you want.
What is wrong with this? This gives full control without larding up the api.
Setting a callback on seek makes no sense as seek isn't an async call. I
understand what you are trying to accomplish but I hope you can see how you
make an incredibly rare use case slightly easier while making all other usage
more complex (because now everyone needs to puzzle over why a synchronous call
takes a callback and what on earth that even means).
> Seek() should take a callback.
> ------------------------------
>
> Key: KAFKA-2390
> URL: https://issues.apache.org/jira/browse/KAFKA-2390
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Jiangjie Qin
> Assignee: Dong Lin
>
> Currently seek is an async call. To have the same interface as other calls
> like commit(), seek() should take a callback. This callback will be invoked
> if the position to seek triggers OFFSET_OUT_OF_RANGE exception from broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
