Enable fairness on Kinesis Source's SynchronousQueue #105
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes a possible problem in which some Kinesis shards progress more quickly than others. Each KCL shard processor has its own thread, and each calls `queue.put()` on the synchronous queue. It is possible that by luck some shard/threads were having their `put()` accepted by a consumer more quickly.
istreeter
force-pushed
the
kinesis-queue-fairness
branch
from
8fcbbc6 to
6132477
Compare
pondzix
approved these changes
Jan 9, 2025
istreeter
added a commit
that referenced
this pull request
Jan 9, 2025
Currently in common-streams apps, the _application_ (i.e. not this library) is responsible for tracking latency of events consumed from the stream. Because of the way it is implemented in the apps, if an event gets stuck (e.g. cannot be written to destination) then the latency drops to zero for the period when the app is retrying the stuck event. This commit aims to fix the problem where the `latency_millis` metric wrongly drops to zero: 1. The `SourceAndAck` is now responsible for tracking the latency metric and pushing the metric to the app. This consolidates the metric across multiple apps into one place 2. The Metrics class allows metric starting values to be wrapped in and Effect, i.e. `F[Metrics.State]`. This means the application can pass in the latency reported by the Source. 3. The `TokenedEvents` now does not contain a stream timestamp. The downstream app has no business knowing the stream timestamp, now that latency is calculated inside common-streams lib. 4. The `LowLevelSource` no longer provides a `lastLiveness`. Instead, the low level source is expected to periodically emit a `None` whenever it is healthy. The higher level `SourceAndAck` then takes responsibility for monitoring whether the low level source is healthy. 5. As a result of these changes, the `SourceAndAck` emits a latency metric of zero whenever the source is genuinely healthy but there are no events to be pulled. This means the app's latency metric is only zero if there are no events. This is better than the previous situation, where the app might mis-leadingly emit a zero latency when the app is stuck, e.g. cannot connect to warehouse.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a possible problem in which some Kinesis shards progress more quickly than others. Each KCL shard processor has its own thread, and each calls
queue.put()on the synchronous queue. It is possible that by luck some shard/threads were having theirput()accepted by a consumer more quickly.