Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: More description around the Timer class

...

  • beginningOffsets
  • close
  • commitSync
  • committed
  • endOffsets
  • listTopics
  • offsetsForTimes
  • partitionsFor
  • position

TBD

Network I/O Timeouts

In most cases, the timeouts provided by users are mostly used to time-bound network I/O. The communication between the client and brokers is going to constitute the majority of the time for those operations. Allowing the user to provide an upper bound on the total time of these operations provides some protection against network issues.

When an API that performs network I/O is invoked, the Consumer will arrange to have one or more network requests issued to the Kafka cluster. Under the covers, the consumer uses the NetworkClient.send() API that takes a ClientRequest. ClientRequest represents a distinct network request, which includes a timeout value, which will be the smaller of the request.timeout.ms configuration value and the remaining timeout value.

Timer

When a user provides a timeout value to a Consumer API, a Timer object is immediately created to track the elapsed/remaining time for processing. While a Duration object provides a fixed value of the overall timeout, the Timer tracks how much time remains since it was first created. At certain points during processing, the Timer.update() API is invoked to determine the elapsed/remaining time for processing.

The logic in the Timer class does not in itself magically enforce any timeouts. The code that uses the Timer object must interact with it explicitly to update it and query it to determine the remaining value of the timeout.    

Compatibility

The new consumer should be backward compatible.

...