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

Support commit retries #269

Open
Fokko opened this issue Jan 16, 2024 · 7 comments · May be fixed by #330
Open

Support commit retries #269

Fokko opened this issue Jan 16, 2024 · 7 comments · May be fixed by #330

Comments

@Fokko
Copy link
Contributor

Fokko commented Jan 16, 2024

Feature Request / Improvement

Within Iceberg, when a commit fails because of a concurrent operation, we can retry the operation by loading the latest version of the snapshot, and re-apply the operation.

@nicor88
Copy link

nicor88 commented Jan 16, 2024

Few suggestions on this feature. It will be good to have control of the amount of retries and the retry strategy. After trying out a few retries libraries I found tenacity one of the most complete because it allows different options for retrying.

@Buktoria Buktoria linked a pull request Jan 30, 2024 that will close this issue
Copy link

This issue has been automatically marked as stale because it has been open for 180 days with no activity. It will be closed in next 14 days if no further activity occurs. To permanently prevent this issue from being considered stale, add the label 'not-stale', but commenting on the issue is preferred when possible.

@github-actions github-actions bot added the stale label Jul 15, 2024
Copy link

This issue has been closed because it has not received any activity in the last 14 days since being marked as 'stale'

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 29, 2024
@sungwy
Copy link
Collaborator

sungwy commented Aug 21, 2024

mark not stale

@kevinjqliu
Copy link
Contributor

As a workaround, to manually retry commits, update the table metadata by using

table = table.refresh()

before calling commit() again

@maxlucuta
Copy link

Have also have experience not being able write to tables in highly distributed environments. Refreshing the table in isolation, in addition to adding some retry logic did not work. The solution we found to work involved:

  1. Refreshing the table.
  2. Creating a new transaction from the refreshed table.
  3. Generating new snapshots for the data files involved in the previous transaction.
  4. Trying to commit again, if fails go back to step 1.

@mark-major
Copy link
Contributor

@maxlucuta Yes, that's what I have been using. It would be nice if there would be an internal retry for the commit so the client application doesn't have to be polluted with the retry.

It would be a difficulty to handle the local table metadata object if the retry is pushed to the library level. The commit would succeed, but the metadata object would point to a whole different snapshot.

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

Successfully merging a pull request may close this issue.

6 participants