Status
Current state: Under Discussion
Discussion thread: part 1 and part 2
JIRA:
KAFKA-16368
-
Getting issue details...
STATUS
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
With the upcoming release of 4.0, we have an opportunity to revisit the constraints and defaults for various Kafka configurations. Each of the proposed change to configuration(s) in this KIP has a specific motivation list next to it.
Public Interfaces
| Component | Configuration name | Diff in default value (only lists the changed values) | Diff in constraints (only lists the changed values) |
|---|---|---|---|
| broker | segment.ms | Unchanged | Previous: min = 1ms New: min = 10000 ms (10s) |
| broker | segment.bytes | ||
| broker | metadata.log.segment.ms | ||
| broker | metadata.log.segment.bytes | ||
| broker | num.recovery.threads.per.data.dir | Previous: 1 New: 2 |
Proposed Changes
Config(s): segment.ms / segment.bytes / metadata.log.segment.ms / metadata.log.segment.bytes
Motivation for the change
Proposed change
Config(s): num.recovery.threads.per.data.dir
Motivation for the change
Proposed change
Compatibility, Deprecation, and Migration Plan
- What impact (if any) will there be on existing users?
- If we are changing behavior how will we phase out the older behavior?
- If we need special migration tools, describe them here.
- When will we remove the existing behavior?
Test Plan
Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?
Rejected Alternatives
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.