-
Notifications
You must be signed in to change notification settings - Fork 130
[PAN-2196] Implement world state cancel #867
[PAN-2196] Implement world state cancel #867
Conversation
Return an error if run() is called on an already running downloader.
return future; | ||
} | ||
|
||
public void cancel() { | ||
// TODO | ||
getFuture().cancel(true); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - good catch.
There was a problem hiding this 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.
This reverts commit f032879.
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 statusrun
is called on an already running instance.