...

1. A secondary method will be added, but with an extra parameter timeout ,as well as a variable giving the TimeUnit, which bounds the amount of time spent.
2. A TimeoutException ClientTimeoutException will be thrown once the amount of time spent exceeds timeout.

...

1. KafkaConsumer#poll(), since it returns offsets, will return nothing.

2. A ClientTimeoutException will be introduced to allow users to more clearly identify the reason why the method timed out. (e.g. LeaderNotAvailable, RequestTimeout etc)

3. A ClientTimeoutException A TimeoutException will be thrown on for other time-bounded methodsmethods when it times out, citing the cause as a "RequestTimeout".

Note: In the current version, fetchCommittedOffsets() will block forever if the committed offsets cannot be fetched successfully and affect position() and

...

Since old methods will not be modified, preexisting data frameworks will not be affected. However, these methods might be deprecated in favor of methods which are bound by a specific time limit.

Feasible and Rejected Alternatives

In discussion, many have raised the idea of using a new config to set timeout time for methods which is being changed in this KIP.  It would not be recommended to use one config for all methods. However, we could use it for similar methods (e.g. methods which call updateFetchPositions() will block using one timeout configured by the user). In this manner, we could incorporate both the config and the added timeout parameter into the code.

One alternative was to add a timeout parameter to to the current position() and other methods. However, the changes made by the user will be much more extensive then basing the time constraint on  requestTimeoutMs because the method signature has been changed. 

...