[
https://issues.apache.org/jira/browse/KAFKA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohan Desai updated KAFKA-7311:
-------------------------------
Description: Sender/RecordAccumulator never resets the next batch expiry
time. Its always computed as the min of the current value and the expiry time
for all batches being processed. This means that its always set to the expiry
time of the first batch, and once that time has passed Sender starts spinning
on epoll with a timeout of 0, which consumes a lot of CPU. This patch updates
Sender to reset the next batch expiry time on each poll loop so that a new
value reflecting the expiry time for the current set of batches is computed.
(was: Sender does not reset next batch expiry time between poll loops. This
means that once it crosses the expiry time of the first batch, it starts
spinning on epoll with a timeout of 0, which consumes a lot of CPU. We observed
this running KSQL when investigating why throughput would drop after about 10
minutes (the default delivery timeout).)
> Sender should reset next batch expiry time between poll loops
> -------------------------------------------------------------
>
> Key: KAFKA-7311
> URL: https://issues.apache.org/jira/browse/KAFKA-7311
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 2.1.0
> Reporter: Rohan Desai
> Priority: Major
> Fix For: 2.1.0
>
>
> Sender/RecordAccumulator never resets the next batch expiry time. Its always
> computed as the min of the current value and the expiry time for all batches
> being processed. This means that its always set to the expiry time of the
> first batch, and once that time has passed Sender starts spinning on epoll
> with a timeout of 0, which consumes a lot of CPU. This patch updates Sender
> to reset the next batch expiry time on each poll loop so that a new value
> reflecting the expiry time for the current set of batches is computed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
