Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stream-Cuts get saved as "Checkpoints" in Reader Group State #5203

Closed
pbelgundi opened this issue Sep 18, 2020 · 2 comments · Fixed by #5244
Closed

Stream-Cuts get saved as "Checkpoints" in Reader Group State #5203

pbelgundi opened this issue Sep 18, 2020 · 2 comments · Fixed by #5244

Comments

@pbelgundi
Copy link
Contributor

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:

synchronizer.updateStateUnconditionally(new CreateCheckpoint(checkpointId));

https://github.com/pravega/pravega/blob/e3d71202d057be75fbcca27cbef1963195626d60/client/src/main/java/io/pravega/client/stream/impl/CheckpointState.java
private String updateGroupStateIfNeeded() throws ReaderNotInReaderGroupException {

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.

@tkaitchuck
Copy link
Member

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?

@pbelgundi
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants