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

[FLINK-33932][checkpointing] Add retry mechanism in RocksDBStateUploader #23986

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

xiangyuf
Copy link
Contributor

What is the purpose of the change

Add retry mechanism in RocksDBStateUploader

Brief change log

  • Introduce RetryStrategy in RocksDBStateUploader when uploadFilesToCheckpointFs

Verifying this change

This change added tests and can be verified as follows:

  • Added Unit Test

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): no
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? no

@flinkbot
Copy link
Collaborator

flinkbot commented Dec 25, 2023

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

Copy link
Contributor

@pnowojski pnowojski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, I've left a couple of comments. Apart of those could you implement a test for this in RocksDBStateUploader? You could inject a testing CheckpointStreamFactory that throws a configured amount of exceptions first.

Comment on lines 60 to 62
private static final int DEFAULT_RETRY_TIMES = 3;

private static final Duration DEFAULT_RETRY_DELAY = Duration.ofSeconds(1L);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be configurable and most likely in the first release default to the current behaviour.

stateScope,
closeableRegistry,
tmpResourcesRegistry)),
() -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please extract to separate method.

Comment on lines 153 to 156
TimeUnit.MILLISECONDS.sleep(
retryStrategy
.getRetryDelay()
.toMillis());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to not synchronously wait on the timeout, and free up the thread pool to do other things.

@Zakelly
Copy link
Contributor

Zakelly commented Feb 20, 2024

Sorry for jumping in but may I ask about the current status?

@xiangyuf
Copy link
Contributor Author

Sorry for jumping in but may I ask about the current status?

Hi @Zakelly , I'm still working on FLIP-414 to support a more general retry mechanism for all statebackends.

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