Branch:
trunk
0.10.0
0.10.1
0.10.2
0.11.0
0.7
0.7.0
0.7.1
0.7.2
0.8
0.8.0-beta1-candidate1
0.8.1
0.8.2
0.9.0
1.0
1.1
2.0
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.x
3.0
3.1
3.2
3.3
3.4
3.5
3.6
KAFKA-14367-join-group
KAFKA-14496-fix-oauth-encoder
KAFKA-15311
add-assignor-log-generation
cmccabe_2023-04-11_improve_controller_logging
cmccabe_2023-05-10_cleanup
cmccabe_2023-06-21_some_minor_fixes
cmccabe_kip_919
hekai-study-v2.8
john-disable-12049
kafka-10867-improved-task-idling-nolog
kip-866-zk-migration-to-kraft
metashell
minor-alter-isr-scheduling
printer
repro-task-idling-problem
revert-13391-kafka-14561
temp-8436
trunk
txn1
0.10.0.0
0.10.0.0-rc1
0.10.0.0-rc2
0.10.0.0-rc3
0.10.0.0-rc4
0.10.0.0-rc5
0.10.0.0-rc6
0.10.0.1
0.10.0.1-rc0
0.10.0.1-rc1
0.10.0.1-rc2
0.10.1.0
0.10.1.0-rc0
0.10.1.0-rc1
0.10.1.0-rc2
0.10.1.0-rc3
0.10.1.1
0.10.1.1-rc0
0.10.1.1-rc1
0.10.2.0
0.10.2.0-KAFKA-5526
0.10.2.0-rc0
0.10.2.0-rc1
0.10.2.0-rc2
0.10.2.1
0.10.2.1-rc0
0.10.2.1-rc1
0.10.2.1-rc2
0.10.2.1-rc3
0.10.2.2
0.10.2.2-rc0
0.10.2.2-rc1
0.11.0.0
0.11.0.0-rc0
0.11.0.0-rc1
0.11.0.0-rc2
0.11.0.1
0.11.0.1-rc0
0.11.0.2
0.11.0.2-rc0
0.11.0.3-rc0
0.8.0
0.8.0-beta1
0.8.0-beta1-candidate1
0.8.1
0.8.1.0
0.8.1.1
0.8.2-beta
0.8.2.0
0.8.2.0-cp
0.8.2.1
0.8.2.2
0.9.0.0
0.9.0.1
1.0.0
1.0.0-rc0
1.0.0-rc1
1.0.0-rc2
1.0.0-rc3
1.0.0-rc4
1.0.1
1.0.1-rc0
1.0.1-rc1
1.0.1-rc2
1.0.2
1.0.2-rc0
1.0.2-rc1
1.1.0
1.1.0-rc0
1.1.0-rc1
1.1.0-rc2
1.1.0-rc3
1.1.0-rc4
1.1.1
1.1.1-rc0
1.1.1-rc1
1.1.1-rc2
1.1.1-rc3
2.0.0
2.0.0-rc0
2.0.0-rc1
2.0.0-rc2
2.0.0-rc3
2.0.1
2.0.1-rc0
2.1.0
2.1.0-rc0
2.1.0-rc1
2.1.1
2.1.1-rc0
2.1.1-rc1
2.1.1-rc2
2.2.0
2.2.0-rc0
2.2.0-rc1
2.2.0-rc2
2.2.1
2.2.1-rc0
2.2.1-rc1
2.2.2
2.2.2-rc1
2.2.2-rc2
2.3.0
2.3.0-rc1
2.3.0-rc2
2.3.0-rc3
2.3.1
2.3.1-rc0
2.3.1-rc1
2.3.1-rc2
2.4.0
2.4.0-rc0
2.4.0-rc1
2.4.0-rc2
2.4.0-rc3
2.4.0-rc4
2.4.1
2.4.1-rc0
2.5.0
2.5.0-rc0
2.5.0-rc1
2.5.0-rc2
2.5.0-rc3
2.5.1
2.5.1-rc0
2.6.0
2.6.0-rc0
2.6.0-rc1
2.6.0-rc2
2.6.1
2.6.1-rc0
2.6.1-rc1
2.6.1-rc2
2.6.1-rc3
2.6.2
2.6.2-rc0
2.6.2-rc1
2.6.3
2.6.3-rc0
2.7.0
2.7.0-rc0
2.7.0-rc1
2.7.0-rc2
2.7.0-rc3
2.7.0-rc4
2.7.0-rc5
2.7.0-rc6
2.7.1
2.7.1-rc0
2.7.1-rc1
2.7.1-rc2
2.7.2
2.7.2-rc0
2.8.0
2.8.0-rc0
2.8.0-rc1
2.8.0-rc2
2.8.1
2.8.1-rc0
2.8.1-rc1
2.8.2
2.8.2-rc0
3.0.0
3.0.0-rc0
3.0.0-rc1
3.0.0-rc2
3.0.1
3.0.1-rc0
3.0.2
3.0.2-rc0
3.1.0
3.1.0-rc0
3.1.0-rc1
3.1.1
3.1.1-rc0
3.1.1-rc1
3.1.2
3.1.2-rc0
3.2.0
3.2.0-rc0
3.2.0-rc1
3.2.1
3.2.1-rc2
3.2.1-rc3
3.2.2
3.2.2-rc0
3.2.3
3.2.3-rc0
3.3.0
3.3.0-rc1
3.3.0-rc2
3.3.1
3.3.1-rc0
3.3.2
3.3.2-rc0
3.3.2-rc1
3.4.0
3.4.0-rc0
3.4.0-rc1
3.4.0-rc2
3.4.1
3.4.1-rc0
3.4.1-rc1
3.4.1-rc2
3.4.1-rc3
3.5.0
3.5.0-rc0
3.5.0-rc1
3.5.1
3.5.1-rc0
3.5.1-rc1
3.6.0
3.6.0-rc0
3.6.0-rc1
3.6.0-rc2
fetch
kafka-0.7.0-incubating-candidate-9
kafka-0.7.1-incubating-candidate-1
kafka-0.7.1-incubating-candidate-2
kafka-0.7.1-incubating-candidate-3
kafka-0.7.2-incubating-candidate-1
kafka-0.7.2-incubating-candidate-2
kafka-0.7.2-incubating-candidate-3
kafka-0.7.2-incubating-candidate-4
kafka-0.7.2-incubating-candidate-5
show
${ noResults }
3 Commits (trunk)
| Author | SHA1 | Message | Date |
|---|---|---|---|
Ismael Juma
|
16b2d4f3a7
|
MINOR: Self-managed -> KRaft (Kafka Raft) (#10414)
`Self-managed` is also used in the context of Cloud vs on-prem and it can be confusing. `KRaft` is a cute combination of `Kafka Raft` and it's pronounced like `craft` (as in `craftsmanship`). Reviewers: Colin P. McCabe <cmccabe@apache.org>, Jose Sancio <jsancio@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>, Ron Dagostino <rdagostino@confluent.io> |
4 years ago |
Jason Gustafson
|
927edfece3
|
KAFKA-10601; Add support for append linger to Raft implementation (#9418)
The patch adds `quorum.append.linger.ms` behavior to the raft implementation. This gives users a powerful knob to tune the impact of fsync. When an append is accepted from the state machine, it is held in an accumulator (similar to the producer) until the configured linger time is exceeded. This allows the implementation to amortize fsync overhead at the expense of some write latency. The patch also improves our methodology for testing performance. Up to now, we have relied on the producer performance test, but it is difficult to simulate expected controller loads because producer performance is limited by other factors such as the number of producer clients and head-of-line blocking. Instead, this patch adds a workload generator which runs on the leader after election. Finally, this patch brings us nearer to the write semantics expected by the KIP-500 controller. It makes the following changes: - Introduce `RecordSerde<T>` interface which abstracts the underlying log implementation from `RaftClient`. The generic type is carried over to `RaftClient<T>` and is exposed through the read/write APIs. - `RaftClient.append` is changed to `RaftClient.scheduleAppend` and returns the last offset of the expected log append. - `RaftClient.scheduleAppend` accepts a list of records and ensures that the full set are included in a single batch. - Introduce `RaftClient.Listener` with a single `handleCommit` API which will eventually replace `RaftClient.read` in order to surface committed data to the controller state machine. Currently `handleCommit` is only used for records appended by the leader. Reviewers: José Armando García Sancio <jsancio@users.noreply.github.com>, Guozhang Wang <wangguoz@gmail.com> |
4 years ago |
|
Jason Gustafson
|
b7c8490cf4
|
KAFKA-10492; Core Kafka Raft Implementation (KIP-595) (#9130)
This is the core Raft implementation specified by KIP-595: https://cwiki.apache.org/confluence/display/KAFKA/KIP-595%3A+A+Raft+Protocol+for+the+Metadata+Quorum. We have created a separate "raft" module where most of the logic resides. The new APIs introduced in this patch in order to support Raft election and such are disabled in the server until the integration with the controller is complete. Until then, there is a standalone server which can be used for testing the performance of the Raft implementation. See `raft/README.md` for details. Reviewers: Guozhang Wang <wangguoz@gmail.com>, Boyang Chen <boyang@confluent.io> Co-authored-by: Boyang Chen <boyang@confluent.io> Co-authored-by: Guozhang Wang <wangguoz@gmail.com> |
4 years ago |