-
Notifications
You must be signed in to change notification settings - Fork 14.3k
KAFKA-19080 The constraint on segment.ms is not enforced at topic level #19371
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
base: trunk
Are you sure you want to change the base?
Conversation
Hello @junrao, @chia7712 I think there are two possible approaches to resolve this:
|
@m1a2st : Perhaps we could somehow allow the tests to set a small |
Maybe we can add a internal config to allow tests to define small size? |
for example: this.internalSegmentSize = getString(TopicConfig.INTERNAL_SEGMENT_BYTES_CONFIG);
...
public long segmentSize() {
if (internalSegmentSize != null) return Long.parseLong(internalSegmentSize);
return segmentMs;
} |
# Conflicts: # core/src/main/scala/kafka/log/LogCleaner.scala # storage/src/main/java/org/apache/kafka/storage/internals/log/LogConfig.java
A label of 'needs-attention' was automatically added to this PR in order to raise the |
@@ -214,6 +214,9 @@ public class TopicConfig { | |||
"configuration. If message.timestamp.type=CreateTime, the message will be rejected if the difference in " + | |||
"timestamps exceeds this specified threshold. This configuration is ignored if message.timestamp.type=LogAppendTime."; | |||
|
|||
// visible for testing | |||
public static final String INTERNAL_SEGMENT_BYTES_CONFIG = "internal.segment.bytes"; |
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.
TopicConfig
is a public class, so could you please move it to LogConfig
?
@m1a2st could you please check the failed tests? |
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.
@m1a2st : Thanks for the PR. Left a couple of comments.
@@ -186,12 +188,13 @@ public Optional<String> serverConfigName(String configName) { | |||
.define(ServerLogConfigs.CREATE_TOPIC_POLICY_CLASS_NAME_CONFIG, CLASS, null, LOW, ServerLogConfigs.CREATE_TOPIC_POLICY_CLASS_NAME_DOC) | |||
.define(ServerLogConfigs.ALTER_CONFIG_POLICY_CLASS_NAME_CONFIG, CLASS, null, LOW, ServerLogConfigs.ALTER_CONFIG_POLICY_CLASS_NAME_DOC) | |||
.define(ServerLogConfigs.LOG_DIR_FAILURE_TIMEOUT_MS_CONFIG, LONG, ServerLogConfigs.LOG_DIR_FAILURE_TIMEOUT_MS_DEFAULT, atLeast(1), LOW, ServerLogConfigs.LOG_DIR_FAILURE_TIMEOUT_MS_DOC) | |||
.defineInternal(ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_CONFIG, LONG, ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_DEFAULT, atLeast(0), LOW, ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_DOC); | |||
.defineInternal(ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_CONFIG, LONG, ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_DEFAULT, atLeast(0), LOW, ServerLogConfigs.LOG_INITIAL_TASK_DELAY_MS_DOC) | |||
.defineInternal(LogConfig.INTERNAL_SEGMENT_BYTES_CONFIG, INT, null, null, LOW, ServerLogConfigs.LOG_SEGMENT_BYTES_DOC); |
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.
Could we document that this config is for testing?
} | ||
|
||
// visible for testing | ||
def internalApply( |
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.
Instead of having an internalApply
, could we just use the existing apply
and add INTERNAL_SEGMENT_BYTES_CONFIG
to MetadataLogConfig
?
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.
+1 to move the internal config to MetadataLogConfig
, and it would be better to wait #19465 extracting the metadata-related configs from other class to MetadataLogConfig
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 just realized that metadata log uses a different approach to allow tests to use a smaller segment bytes than allowed in production. That approach defines the original segment byte config with a small minimal requirement, but adds METADATA_LOG_SEGMENT_MIN_BYTES_CONFIG to enforce the actual minimal requirement in production. This new config could be changed in tests to allow for smaller minimal bytes. The benefit of this approach is that it allows the existing config to be used directly to set a smaller value for tests. The downside is that the doc for min value is inaccurate and the validation is done through a customized logic.
It would be useful to pick the same strategy between metadata log and regular log. The metadata log approach seems slightly better since it's less intrusive. We could fix the inaccurate min value description for production somehow.
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.
Excuse me, the strategy used by metadata log is to add a "internal" config (METADATA_LOG_SEGMENT_MIN_BYTES_CONFIG
) to change the (metadata) segment size in testing, and that is what we want to address in this PR - we add a "internal" config for regular log, and so the test can use the "smaller" segment size.
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 am just saying that we now have two different ways to achieve the same goal. In the metadata log approach, you set the desired value through the original config, which is segment.bytes. You then set an internal config to change the min constraint.
The approach in this PR is to set the desired value through a different internal config.
It would be useful to choose same approach for both the metadata log and the regular log.
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.
Personally, I prefer the approach of adding "internal".xxx config as it provide better user experience for public configs, allowing users to see the "correct" min value. Additionally, we can remove the customized logic of validation.
In short, I suggest to add following changes to this PR.
- remove
METADATA_LOG_SEGMENT_MIN_BYTES_CONFIG
- remove
MetadataLogConfig#logSegmentMinBytes
- add
internal.metadata.log.segment.bytes
- customize
MetadataLogConfig#logSegmentBytes
as following code
public int logSegmentBytes() {
if (internalSogSegmentBytes != null) return internalSogSegmentBytes;
return logSegmentBytes;
}
The main reason is that we forgot setting the
TopicConfig.SEGMENT_BYTES_CONFIG
at least to1024 * 1024
, thusaddressed it, and add a test for it.