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

RequestQueue#cancelAll race condition #299

Closed
jmjenks opened this issue Oct 10, 2019 · 2 comments
Closed

RequestQueue#cancelAll race condition #299

jmjenks opened this issue Oct 10, 2019 · 2 comments

Comments

@jmjenks
Copy link

jmjenks commented Oct 10, 2019

It is possible for a request to be cancelled after it has already delivered its response. I have set up a custom Request class that overrides cancel() to support a cancel listener in addition to the response and error listeners. I have a scenario where as a response to a request, I issue a cancelAll to cancel all further requests. Perhaps 10% of the time I'm seeing the cancel listeners be notified of the very request that was already handled. It appears this is a race between the request handling thread issuing the cancelAll() and the volley worker thread removing the request from the queue after it was handled. Perhaps the state could be checked to not issue a call to cancel on requests that are already complete?

@jpd236
Copy link
Collaborator

jpd236 commented Oct 10, 2019

Adding a cancel listener in a thread-safe way is actually fairly tricky. See issue #85 and PR #103 for a previous attempt at this. This remains an open feature request but we haven't implemented it yet.

In the mean time, if you are using Volley's default ResponseDelivery which dispatches responses on the main thread, then you could work around this by having whatever invokes your cancel listeners dispatch a runnable to the main thread which checks whether the request is complete and drops the event if so.

@jpd236 jpd236 closed this as completed Oct 10, 2019
@jmjenks
Copy link
Author

jmjenks commented Oct 11, 2019

Thank you for the response. I did work around it by doing something similar to what you described. I just thought the call to cancel an already completed request was a bit odd so thought I'd let you know of the race condition. Thanks!

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

No branches or pull requests

2 participants