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

Split out a double-check-cache job for jvm/rsc compile #8221

Merged

Conversation

stuhood
Copy link
Member

@stuhood stuhood commented Aug 29, 2019

Problem

#8190 moved cache writing out of the completion of the zinc and rsc jobs and into a dependent job. But at the same time, we also had multiple attempts to "double check" the cache happening concurrently due to both the zinc and rsc jobs checking, and that race could lead to partial entries being extracted.

Solution

Since we can't actually cancel or coordinate the concurrent work, we can't safely double check the cache once either job has started. So instead, this change extracts the cache double-check into its own job that both the zinc and rsc tasks will depend on.

@stuhood stuhood changed the title Split out a double-check-cache job jvm/rsc compile Split out a double-check-cache job for jvm/rsc compile Aug 29, 2019
… before starting either rsc or zinc work, and then never again (otherwise hitting the cache might race with the ongoing work, which we are unable to cancel).
@stuhood stuhood force-pushed the stuhood/split-out-a-double-check-cache-job branch from 76c096c to a60f90e Compare August 29, 2019 05:00
Copy link
Contributor

@illicitonion illicitonion left a comment

Choose a reason for hiding this comment

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

Seems reasonable, thanks!

Copy link
Contributor

@blorente blorente left a comment

Choose a reason for hiding this comment

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

Looks good, sans the failing travis shard. At least one of the test looks legitimate: JavaCompileIntegrationTest.test_java_compile_with_corrupt_remote


def __call__(self):
self.count += 1
return self.count

def increment_size(self, by=1):
Copy link
Contributor

Choose a reason for hiding this comment

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

Can this be folded into the __call__ function above?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not without an awkward signature I think: this one increments size, while the other increments count.

@stuhood stuhood merged commit e3cf637 into pantsbuild:master Aug 29, 2019
@stuhood stuhood added this to the 1.19.x milestone Aug 29, 2019
@stuhood stuhood deleted the stuhood/split-out-a-double-check-cache-job branch August 29, 2019 16:08
stuhood added a commit that referenced this pull request Aug 29, 2019
### Problem

#8190 moved cache writing out of the completion of the zinc and rsc jobs and into a dependent job. But at the same time, we also had multiple attempts to "double check" the cache happening concurrently due to both the zinc and rsc jobs checking, and that race could lead to partial entries being extracted.

### Solution

Since we can't actually cancel or coordinate the concurrent work, we can't safely double check the cache once either job has started. So instead, this change extracts the cache double-check into its own job that both the zinc and rsc tasks will depend on.
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 this pull request may close these issues.

3 participants