-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-12758 Added server-common
module to have server side common classes.
#10638
Conversation
ab75beb
to
11bece6
Compare
@junrao As discussed earlier, serde related classes are moved to the new |
server-common
module to have server side common classes. server-common
module to have server side common classes.
cc @cmccabe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@satishd : Thanks for the PR. A few comments below.
@@ -1585,6 +1644,7 @@ project(':shell') { | |||
implementation libs.jacksonJDK8Datatypes | |||
implementation libs.jline | |||
implementation libs.slf4jApi | |||
implementation project(':server-common') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed since core already depends on server-common?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this is needed because core
module does not expose server-common
as a transitive module with gradle api
dependency. It uses implementation
dependency for server-common
to be part of core
module's compile/runtime classpaths.
I am not sure whether we really have usages for server-common
classes to be exposed as part of core
module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core should generally not expose anything with api since core doesn't expose any public api.
@@ -779,6 +779,7 @@ project(':core') { | |||
api project(':clients') | |||
api libs.scalaLibrary | |||
|
|||
implementation project(':server-common') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that needed since server-common is included in metadata/storage already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, it is needed as server-common
is only compile/runtime dependency of raft
and metadata
. But it is not a transitive dependency.
@@ -1267,11 +1269,13 @@ project(':raft') { | |||
archivesBaseName = "kafka-raft" | |||
|
|||
dependencies { | |||
implementation project(':server-common') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed since server-common is included in metadata?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pl see the earlier comment.
build.gradle
Outdated
archivesBaseName = "kafka-server-common" | ||
|
||
dependencies { | ||
implementation project(':clients') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since server-common depends on clients, perhaps we could remove clients from all modules that depend on server-common?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not add clients
as api
dependency. We may need to do that as the users of server-common
need org.apache.kafka.common.protocol
classes as they are part of the APIs in server-common
classes.
After this change, we can remove clients
dependency from wherever server-common
module is directly used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the change with the commit 1e259ff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should remove the clients dependency since those modules rely on clients classes independently of their server-common dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point @ijuma. It makes sense to me to have explicit client dependency irrespective of server-common
dependency.
@@ -1070,6 +1071,7 @@ project(':metadata') { | |||
archivesBaseName = "kafka-metadata" | |||
|
|||
dependencies { | |||
implementation project(':server-common') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not directly related to this PR. Do you know why we only include the storage module in releaseTarGz target, but not other server side modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. It looks like these are already copied as part of configurations.runtimeClasspath
. I raised #10647 to fix that.
@@ -1345,6 +1349,62 @@ project(':raft') { | |||
} | |||
} | |||
|
|||
project(':server-common') { | |||
archivesBaseName = "kafka-server-common" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to move the classes in storage-api here? It helps reduce one module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plan to do that in another PR. I have not yet decided whether to have a separate sub module like server-api
or part of server-common
module. server-api
module can contain all the server related public API classes including storage, security etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good question and worth thinking about a bit more. I agree we can do it in a separate PR. I think the main thing to consider is how we differentiate between public classes exposed to users and common classes to be used by the kafka server modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created https://issues.apache.org/jira/browse/KAFKA-12757 to discuss more on this.
Moved ApiMessageAndVersion, RecordSerde, AbstractApiMessageSerde, and BytesApiMessageSerde to server-common module.
…ntation' to 'api' to make it as a trasitive dependency as classes in 'server-common' module expose some of the 'clients' classes used. Addressed review comments
Thanks @junrao for the review comments. Pl see inline replies and the latest commits. |
|
||
sourceSets { | ||
main { | ||
java { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we only going to allow Java sources in this new module? (I think that's probably a good idea)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@satishd LGTM. Thanks for the PR!
…e-allocations-lz4 * apache-github/trunk: (155 commits) KAFKA-12728: Upgrade gradle to 7.0.2 and shadow to 7.0.0 (apache#10606) KAFKA-12778: Fix QuorumController request timeouts and electLeaders (apache#10688) KAFKA-12754: Improve endOffsets for TaskMetadata (apache#10634) Rework on KAFKA-3968: fsync the parent directory of a segment file when the file is created (apache#10680) MINOR: set replication.factor to 1 to make StreamsBrokerCompatibilityService work with old broker (apache#10673) MINOR: prevent cleanup() from being called while Streams is still shutting down (apache#10666) KAFKA-8326: Introduce List Serde (apache#6592) KAFKA-12697: Add Global Topic and Partition count metrics to the Quorum Controller (apache#10679) KAFKA-12648: MINOR - Add TopologyMetadata.Subtopology class for subtopology metadata (apache#10676) MINOR: Update jacoco to 0.8.7 for JDK 16 support (apache#10654) MINOR: exclude all `src/generated` and `src/generated-test` (apache#10671) KAFKA-12772: Move all transaction state transition rules into their states (apache#10667) KAFKA-12758 Added `server-common` module to have server side common classes. (apache#10638) MINOR Removed copying storage libraries specifically as they are already copied. (apache#10647) KAFKA-5876: KIP-216 Part 4, Apply InvalidStateStorePartitionException for Interactive Queries (apache#10657) KAFKA-12747: Fix flakiness in shouldReturnUUIDsWithStringPrefix (apache#10643) MINOR: remove unnecessary placeholder from WorkerSourceTask#recordSent (apache#10659) MINOR: Remove unused `scalatest` definition from `dependencies.gradle` (apache#10655) MINOR: checkstyle version upgrade: 8.20 -> 8.36.2 (apache#10656) KAFKA-12464: minor code cleanup and additional logging in constrained sticky assignment (apache#10645) ...
…lasses. (apache#10638) Added server-common module to have server side common classes. Moved ApiMessageAndVersion, RecordSerde, AbstractApiMessageSerde, and BytesApiMessageSerde to server-common module. Reivewers: Kowshik Prakasam <[email protected]>, Jun Rao <[email protected]>
…lasses. (apache#10638) Summary: Added server-common module to have server side common classes. Moved ApiMessageAndVersion, RecordSerde, AbstractApiMessageSerde, and BytesApiMessageSerde to server-common module. apache-reviewers: Kowshik Prakasam <[email protected]>, Jun Rao <[email protected]> (cherry picked from commit 7ef3879) Reviewers: #ldap_kafka_admins, kchandraprakash Reviewed By: #ldap_kafka_admins, kchandraprakash JIRA Issues: DKAFC-868 Differential Revision: https://code.uberinternal.com/D6303277
…lasses. (apache#10638) Summary: Added server-common module to have server side common classes. Moved ApiMessageAndVersion, RecordSerde, AbstractApiMessageSerde, and BytesApiMessageSerde to server-common module. apache-reviewers: Kowshik Prakasam <[email protected]>, Jun Rao <[email protected]> (cherry picked from commit 7ef3879) Reviewers: #ldap_kafka_admins, kchandraprakash Reviewed By: #ldap_kafka_admins, kchandraprakash JIRA Issues: DKAFC-868 Differential Revision: https://code.uberinternal.com/D6303277
server-common
module to have server side common classes.ApiMessageAndVersion
,RecordSerde
,AbstractApiMessageSerde
, andBytesApiMessageSerde
to server-common module.Existing tests are sufficient as this change is about moving files into a separate module.
Committer Checklist (excluded from commit message)