Skip to content

Spark 3.2: Refactor TestRemoveOrphanFilesAction - remove Thread.sleep()#4711

Merged
rdblue merged 1 commit intoapache:masterfrom
kasasi:spark3.2_refactor_test_remove_orphan_files_action
May 10, 2022
Merged

Spark 3.2: Refactor TestRemoveOrphanFilesAction - remove Thread.sleep()#4711
rdblue merged 1 commit intoapache:masterfrom
kasasi:spark3.2_refactor_test_remove_orphan_files_action

Conversation

@ulmako
Copy link
Copy Markdown
Contributor

@ulmako ulmako commented May 6, 2022

Follow up to PR #4307 refactoring the TestRemoceOrphanFilesAction class and replace thread.sleep() with calls to waitUntilAfter() method.

@github-actions github-actions bot added the spark label May 6, 2022
@ulmako
Copy link
Copy Markdown
Contributor Author

ulmako commented May 6, 2022

@kbendick @rdblue here is the refactoring PR we talked about in #4307. Would you mind taking a look at it?

@szehon-ho
Copy link
Copy Markdown
Member

Looks reasonable to me, if its just for tests, should we just do all the spark versions in one pr to reduce overhead? Not sure what people think.

@kbendick
Copy link
Copy Markdown
Contributor

kbendick commented May 6, 2022

I'm ok with either all versions or back-porting by version. Technically by version is the standard but for small things we do often do multiple versions at once.

Side question: Am I correct in assuming that for cherry-picking in a fork that all versions at once for smaller things is preferred for your workflow @szehon-ho? Ideally we do whatever is most practical for end users (within reason), which includes people who actively maintain forks.


// sleep for 1 second to unsure files will be old enough
Thread.sleep(1000);
waitUntilAfter(System.currentTimeMillis());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this will jsut immediately return. The waitUntilAfter function loops while the passed in timestamp is less than System.currentTimeMillis.

Other places I see waitUntilAfter used tend to wait until table.currentSnapshot.timestampMillis(). But in this file it does seem that this is how waitUntilAfter is used, so I'm ok with this.

If we notice this being flakey, then we might want to change it to using the table's current snapshot timestamp instead.

@szehon-ho
Copy link
Copy Markdown
Member

@kbendick no strong opinion or workflow (my only thought there was ease of reviewing), I'm fine to do separate prs as well.

@rdblue rdblue merged commit a0c42b4 into apache:master May 10, 2022
@rdblue
Copy link
Copy Markdown
Contributor

rdblue commented May 10, 2022

Thanks, @ulmako! Good to have this fixed.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants