You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.
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
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: