Skip to content
This repository has been archived by the owner on Sep 26, 2019. It is now read-only.

[PAN-2196] Implement world state cancel #867

Merged

Conversation

mbaxter
Copy link
Contributor

@mbaxter mbaxter commented Feb 14, 2019

PR description

Implement world state download cancellation functionality. On cancellation, the WorldStateDownloader will cancel any pending network tasks and clear its task queue. Also made a few other small changes:

  • Removed the status tracking from the downloader in favor of using the future as a signal on the status.
  • Modified the downloader to return an exceptional result if run is called on an already running instance.

@mbaxter mbaxter requested a review from ajsutton February 14, 2019 22:55
return future;
}

public void cancel() {
// TODO
getFuture().cancel(true);
Copy link
Contributor

Choose a reason for hiding this comment

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

Given that the use case for this is likely to be cancelling one download and immediately starting a new one for a later block, how do we avoid a race condition where outstanding requests and/or handleCancellation are still happening after this method returns and a new download starts?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just to think this through a bit more...

When you can cancel, that same thread will be used to run any follow actions added via whenComplete, thenApply and friends. So if you call WorldStateDonwloader.cancel by the time that method returns we do actually know that handleCancellation has completed. However, we don't know if handleCancellation runs before or after anything else that was chained to that future.

I think that will probably work out ok but we may want to have createFuture return the future returned from whenComplete instead of the original to fix it (just need to make sure it doesn't interfere with whether the returned future completes exceptionally or not).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another good catch. I think I broke this when I removed the status var. I reverted that change and now you shouldn't be able to execute run() before the cancellation has finished because the checks are now based on the status variable which gets updated inside of the synchronized handleCancellation method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went ahead and merged because I have another branch built on top of this one. But if you see any issues with my follow-up updates, I can fix them in another PR.

try {
db.deleteRange(from, to);
lastDequeuedKey.set(0);
lastEnqueuedKey.set(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to set oldestKey to 0 as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes - good catch.

Copy link
Contributor

@ajsutton ajsutton left a comment

Choose a reason for hiding this comment

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

Need to check on the clearing of oldestKey and might be nice to fix the chaining of the cancellation handler but I've convinced myself this does what we need so LGTM.

@mbaxter mbaxter merged commit c2262f5 into PegaSysEng:master Feb 15, 2019
rain-on pushed a commit to rain-on/pantheon that referenced this pull request Feb 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants