[
https://issues.apache.org/jira/browse/KAFKA-16937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865164#comment-17865164
]
Greg Harris edited comment on KAFKA-16937 at 7/11/24 5:15 PM:
--------------------------------------------------------------
I thought about this some more. Right now there is a lot of code that depends
on the passage of time. Every time someone uses
Future/CountDownLatch/Barrier/Semaphore/etc, time affects whether the operation
succeeds or fails.
If we were to try to mock these with the Time interface, it would involve very
large changes, and make nearly every class dependent on the Time interface.
While this would express the concept that a lot of our code is dependent on the
passage of time, the Time interface becomes a sort of "God Object" whose
implementation affects the implementation of every other piece of code.
Rather than taking the current implementations of Kafka that depend on the
passage of time and change them to depend on the Time class, I think we should
strive to remove our dependence on the passage of time whenever possible.
Perhaps rather than having timeouts occur deep within a code path, we can use
the cancellation like golang: [https://go.dev/doc/database/cancel-operations]
and push the dependence on time outward. When we're implementing new
functionality, we should avoid depending functionally on time whenever possible.
was (Author: gharris1727):
I thought about this some more. Right now there is a lot of code that depends
on the passage of time. Every time someone uses
Future/CountDownLatch/Barrier/Semaphore/etc, tn
If we were to try to mock these with the Time interface, it would involve very
large changes, and make nearly every class dependent on the Time interface.
While this would express the concept that a lot of our code is dependent on the
passage of time, the Time interface becomes a sort of "God Object" whose
implementation affects the implementation of every other piece of code.
Rather than taking the current implementations of Kafka that depend on the
passage of time and change them to depend on the Time class, I think we should
strive to remove our dependence on the passage of time whenever possible.
Perhaps rather than having timeouts occur deep within a code path, we can use
the cancellation like golang: [https://go.dev/doc/database/cancel-operations]
and push the dependence on time outward. When we're implementing new
functionality, we should avoid depending functionally on time whenever possible.
> Consider inlineing Time#waitObject to ProducerMetadata#awaitUpdate
> ------------------------------------------------------------------
>
> Key: KAFKA-16937
> URL: https://issues.apache.org/jira/browse/KAFKA-16937
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: PoAn Yang
> Priority: Minor
>
> Time#waitObject is implemented by while-loop and it is used by
> `ProducerMetadata` only. Hence, this jira can include following changes:
> 1. move `Time#waitObject` to `ProducerMetadata#awaitUpdate`
> 2. ProducerMetadata#awaitUpdate can throw "exact" TimeoutException [0]
> [0]
> https://github.com/apache/kafka/blob/23fe71d579f84d59ebfe6d5a29e688315cec1285/clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java#L1176
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
