You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Greg Harris (Jira)" <ji...@apache.org> on 2023/02/24 22:53:00 UTC

[jira] [Created] (KAFKA-14760) Move ThroughputThrottler, break connect-runtime dependency on tools

Greg Harris created KAFKA-14760:
-----------------------------------

             Summary: Move ThroughputThrottler, break connect-runtime dependency on tools
                 Key: KAFKA-14760
                 URL: https://issues.apache.org/jira/browse/KAFKA-14760
             Project: Kafka
          Issue Type: Task
          Components: KafkaConnect, tools
            Reporter: Greg Harris
            Assignee: Greg Harris


Currently there is only one dependency on the `tools` module, `connect-runtime`.
This dependency is only for one class, the ThroughputThrottler. This class is used by:

1. tools main ProducerPerformance
2. tools main VerifiableProducer
3. runtime main SchemaSourceConnector
4. runtime main VerifiableSourceConnector
5. runtime test MonitorableSourceConnector

For KAFKA-14627, I want to be able to have `tools` (test) depend on `connect-runtime` (test). This is because we are adding a connect-specific command-line utility, and wish to re-use some of the existing connect test infrastructure to unit test the new command-line utility. Unfortunately naively adding this new dependency to tools causes a circular dependency that prevents the project from building.

Instead of refactoring the connect-specific test utilities out to a new package that both runtime and tools can depend on, it appears to make more sense to move the more generic `ThroughputThrottler` class into some common package.

This common package could be:
1. clients
2. server common
3. some other existing package which would be a new dependency for tools
4. a new package consisting of just the `ThroughputThrottler` class

I'm not sure which one of these makes the most sense, and would appreciate guidance on what would make the most sense for ownership and maintenance.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)