You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem description
Stream-Cuts can be generated on a Stream by invoking the generateStreamCut() API on a ReaderGroup.
Internally the mechanism used to generate a Stream-Cut as same as the mechanism for generating a checkpoint.
However, a "Stream-Cut" is conceptually a different thing from a checkpoint.
Stream-Cuts generated by generateStreamCut() API should be returned to the user and there is no need to store them as a checkpoint in the RGState
This is what happens internally today as we don't distinguish between Stream-Cuts and Checkpoints.
This would interfere with the use of checkpoints for truncation when implementing Consumption Based Retention on Client.
Suggestions for an improvement
Stream-Cut generation should not have any impact on Checkpoint generation and generated Stream-Cuts should not be stored as checkpoints in RGState.
The text was updated successfully, but these errors were encountered:
I am not clear what the actual problem here is. Stream cuts need to coordinate across all of the readers to gather their current position in the exact same way as a checkpoint. In fact a checkpoint is a type of stream cut. So what is the benefit of duplicating the code to do this?
@tkaitchuck the problem is with storing the StreamCut as a checkpoint in the lastCheckpointedPosition.
And that is what we're aiming to fix.
This is necessary for implementing CBR correctly which requires publishing every completed checkpoint (and not streamcut) to Controller as a truncation point.
Problem description
Stream-Cuts can be generated on a Stream by invoking the generateStreamCut() API on a ReaderGroup.
Internally the mechanism used to generate a Stream-Cut as same as the mechanism for generating a checkpoint.
However, a "Stream-Cut" is conceptually a different thing from a checkpoint.
Stream-Cuts generated by generateStreamCut() API should be returned to the user and there is no need to store them as a checkpoint in the RGState
This is what happens internally today as we don't distinguish between Stream-Cuts and Checkpoints.
This would interfere with the use of checkpoints for truncation when implementing Consumption Based Retention on Client.
Problem location
Client Code:
pravega/client/src/main/java/io/pravega/client/stream/impl/ReaderGroupImpl.java
Line 373 in 6acd317
https://github.com/pravega/pravega/blob/e3d71202d057be75fbcca27cbef1963195626d60/client/src/main/java/io/pravega/client/stream/impl/CheckpointState.java
pravega/client/src/main/java/io/pravega/client/stream/impl/EventStreamReaderImpl.java
Line 258 in ca0cbdd
Suggestions for an improvement
Stream-Cut generation should not have any impact on Checkpoint generation and generated Stream-Cuts should not be stored as checkpoints in RGState.
The text was updated successfully, but these errors were encountered: