Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
Description
As part of the restoration optimization effort, we would like to move the restoration process to separate threads such that:
1. Stream threads would not be restricted by the main consumer `poll` frequency to keep as part of the group.
2. We can allow larger batches of data to be written into the restoration.
Besides this, we'd also like to fix the known issues that for piggy-backed source topics as changelog topics, the serde exception / extra processing logic would be skipped.
We would also cleanup the global update tasks as part of this effort to consolidate to the separate restoration threads, and would also gear them up with corresponding monitoring metrics (KIPs in progress).
Attachments
Issue Links
- blocks
-
KAFKA-14192 Move registering and unregistering changelogs to state updater
- Open
- contains
-
KAFKA-13295 Long restoration times for new tasks can lead to transaction timeouts
- Resolved
-
KAFKA-10575 StateRestoreListener#onRestoreEnd should always be triggered
- Resolved
- is blocked by
-
KAFKA-16336 Remove Deprecated metric standby-process-ratio
- Resolved
- is related to
-
KAFKA-14548 Stable streams applications stall due to infrequent restoreConsumer polls
- Resolved
-
KAFKA-7934 Optimize restore for windowed and session stores
- Open
-
KAFKA-8023 Improve global state store restoration by using multiple update threads
- Open
-
KAFKA-13239 Use RocksDB.ingestExternalFile for restoration
- Open
-
KAFKA-8037 KTable restore may load bad data
- Open
-
KAFKA-13500 Consider adding a dedicated standby consumer
- Open
-
KAFKA-7663 Custom Processor supplied on addGlobalStore is not used when restoring state from topic
- Resolved
- relates to
-
KAFKA-10005 Decouple RestoreListener from RestoreCallback and not enable bulk loading for RocksDB
- Resolved
-
KAFKA-16567 Add New Stream Metrics based on KIP-869
- Resolved
- links to
- mentioned in
-
Page Loading...