You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kafka sink use a dedicated thread for potentially blocking send
In #431 we improved performance of the Kafka
sink by calling `producer.send()` on a compute thread not on a blocking
thread. This is a great improvement if it is always true that
`producer.send()` never blocks.
But `producer.send()` does in fact block if the producer needs to
re-fetch topic metadata. This happens every 5 minutes by default, and
is configured by the kafka setting `metadata.max.age.ms`. If
`producer.send()` blocks on a compute thread, then it can potentially
cause thread starvation, and negatively impact the collector's
responsiveness to requests.
This PR changes to executing `send()` on a dedicated thread. From the
point of view of the collector, it is ok if `send()` is blocking on the
dedicated thread. It is better than running it inside `Sync[F].blocking`
(which is what we did before) because that tended to create a huge
number of threads under some circumstances.
In theory this shouldn't negatively affect performance much, even though
it's a single thread. Because most of the time `send()` does not block;
and when it does block (i.e. once per 5 minutes) then it is ok for the
other events to get enqueued as a backlog of Callables on the thread.
Kafka sink use a dedicated thread for potentially blocking send: Amendment 1
0 commit comments