-
Notifications
You must be signed in to change notification settings - Fork 14k
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-15853: Move KafkaConfig.Defaults to server module #15158
Conversation
d2cd220
to
4f86d1e
Compare
core/src/main/scala/kafka/coordinator/group/GroupCoordinator.scala
Outdated
Show resolved
Hide resolved
*/ | ||
package org.apache.kafka.coordinator.transaction; | ||
|
||
public class TransactionLogConfig { |
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.
Hey @OmniaGM. It is a bit weird to have those transaction classes in the group-coordinator module. It does not seem to be the correct place.
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 feel the same but also not sure where they should move. They don't fit in server module either. I don't see any Jiras to move transaction coordinator out of server but maybe I can start a new module for transaction coordinator similar to the group one. Would this make more sense?
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.
Let's see what @dajac says, but I think a kafka-transactions
or kafka-transactions-coordinator
module that depends on kafka-group-coordinator
makes sense to me. The former option is shorter and as clear while the second follows the same pattern as for the group coordinator
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.
Yeah, creating a new module makes sense to me. I would call it transaction-coordinator
and the jar would be called kafka-transaction-coordinator
in order to follow the naming scheme of the group-coordinator
. I am not sure if it really needs to depend on the group-coordinator module though but I haven't not checked the details.
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.
Yeah, I was using the maven name. I agree that we shouldn't add a dependency unless it exists.
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 added transaction-coordinator
modules and moved theses there
4f86d1e
to
e5da53c
Compare
@OmniaGM Can we rebase to resolve the conflicts? Thanks |
e5da53c
to
bc13fb7
Compare
done now. |
@OmniaGM It looks like there are a few build failures:
|
...coordinator/src/main/java/org/apache/kafka/coordinator/transaction/TransactionLogConfig.java
Outdated
Show resolved
Hide resolved
fixed this |
15ae672
to
e98942c
Compare
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/OffsetConfig.java
Outdated
Show resolved
Hide resolved
*/ | ||
package org.apache.kafka.coordinator.transaction; | ||
|
||
public class TransactionLogConfig { |
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.
Can we introduce new module and config into separate PR?
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.
it will be very small one which I don't believe it worth it.
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.
Thanks for the PR. It looks good overall, I just left a few suggestions
server/src/main/java/org/apache/kafka/server/config/Defaults.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/apache/kafka/server/config/Defaults.java
Outdated
Show resolved
Hide resolved
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.
LGTM, thanks
import java.util.concurrent.TimeUnit; | ||
import java.util.stream.Collectors; | ||
|
||
public class Defaults { |
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.
What's the plan for these defaults, they will not be part of KafkaConfig
anymore once that's moved to this 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.
- They always have been separate object out side of KafkaConfig but in the same file. I just moved them out for reason no. 2
- Kafkaconfig cant be refactored into Java as one class as it is huge and breaks the complexity rules for the checkstyle. The plan is to keep them out as separate class.
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.
- If you look at the pattern in Java, the defaults are usually in the same file as the config file unless it's shared between many configs (then it's extracted).
- We can add an exception for checkstyle - it's a tool in the end.
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 think the pattern of default and properties in the class object companion has been like this in some scala as well. KafkaConfig has been kinda of anti pattern for a while as the defaults are defined in another object companian. I will raise another pr soon to move this pr to Java pattern.
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.
pr opened here to refactor this #15260
Reviewers: Mickael Maison <[email protected]>, Ismael Juma <[email protected]> , David Jacot <[email protected]>, Nikolay <[email protected]>
The uniform assignor got accidentally removed by #15158. This patch adds it back. Reviewers: Omnia G H Ibrahim <[email protected]>, Mickael Maison <[email protected]>
Reviewers: Mickael Maison <[email protected]>, Ismael Juma <[email protected]> , David Jacot <[email protected]>, Nikolay <[email protected]>
The uniform assignor got accidentally removed by apache#15158. This patch adds it back. Reviewers: Omnia G H Ibrahim <[email protected]>, Mickael Maison <[email protected]>
Reviewers: Mickael Maison <[email protected]>, Ismael Juma <[email protected]> , David Jacot <[email protected]>, Nikolay <[email protected]>
The uniform assignor got accidentally removed by apache#15158. This patch adds it back. Reviewers: Omnia G H Ibrahim <[email protected]>, Mickael Maison <[email protected]>
Reviewers: Mickael Maison <[email protected]>, Ismael Juma <[email protected]> , David Jacot <[email protected]>, Nikolay <[email protected]>
The uniform assignor got accidentally removed by apache#15158. This patch adds it back. Reviewers: Omnia G H Ibrahim <[email protected]>, Mickael Maison <[email protected]>
first pr to break #15103
ClientQuotaManagerConfig
, andReplicationQuotaManagerConfig
object companions moved toorg.apache.kafka.server.config
in another pr need to be merged firstTransactionLogConfig
object companion moved toorg.apache.kafka.coordinator.transaction
OffsetConfig
moved toorg.apache.kafka.coordinator.group
Committer Checklist (excluded from commit message)