Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

Issue with MKNetworkOperation Cancel Logic Causing Shared Queue Size to Grow as Application Runs #449

Open
kglee79 opened this issue Feb 4, 2015 · 0 comments

Comments

@kglee79
Copy link

kglee79 commented Feb 4, 2015

I was having an issue where trying to issue many POST's rapidly would cause everything to freeze up. So I started debugging the freeze process and monitoring the shared queue size and noticed that most of the operations that were cancelled kept showing up and never going away.

I believe I found the bug. The shared queue size is growing as none of the operations are being marked "finished" (MKNetworkOperationsStateFinished) if they are in the MKNetworkOperationsStateReady state and cancelled. In MKNetworkOperation.m, just before the end of the cancel method, it checks to see if the state is MKNetworkOperationsStateExecuting and then flips it to MKNetworkOperationsStateFinished. However, that leaves operations that are still not yet executing and only in the ready state, in the operations queue forever since they are never being marked finished. This causes the operations that are cancelled and not in the finished state to be frozen at every network disconnect and then enqueued again at every connect. Eventually this causes everything to stop working. I believe the fix is to change

if(self.state == MKNetworkOperationStateExecuting)

to

if(self.state == MKNetworkOperationStateExecuting || self.state == MKNetworkOperationStateReady )

Has anyone else had the same issue? I didn't find it in any of the previously reported issues, however the issue presents itself pretty quickly and since this framework is widely used, I was expecting to see reports on this. Wondering if there might be something else I'm doing incorrectly, but after modifying the "if" statement, everything works as expected.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant