Background
I am creating a series of requests to grab a chunk of a file. The chunk size stays the same so the number of requests may change depending on which file I am downloading. For smaller files, and thus smaller number of requests I seem to reliably succeed. However once my request chain reaches the 10+ ballpark I start to get an error.
Error
I am getting an error from what appears to be Alamofire.
Error code -999 cancelled.
Looking at other purposed solutions
From the searching I have done it seems that this occurs when either the session manager is deallocated or another request was kicked off before I received a response from the previous request.
I made my session manager static, as stated by some other posts to handle the deallocating issue, but I still get this error.
I don't think the next request is being called before the first finishes as my logs seem to be printing out in order and the failure is rather random. I would expect that the requests would overwrite quite reliably.
Is there any thing else that causes this error code to occur?
Additional Logs
NetworkFilesClient.swift:351 - Error downloading chunk URL: MY_URL_HERE,
Range: bytes=29360128-33554432,
Error: Error Domain=NSURLErrorDomain Code=-999 "cancelled"
UserInfo={NSErrorFailingURLKey=MY_URL_HERE,
NSLocalizedDescription=cancelled,
NSErrorFailingURLStringKey=MY_URL_HERE}
What works for me:
sessionManager.session.finishTasksAndInvalidate()
I put this at the end of my response handling. Why? No clue...
Related
I'm using a library to download media. The download function returns a stream. Occasionally, partway through the download, an error occurs in one of the http requests used to yield each item of the stream.
When such an error occurs, I'm currently discarding the entire download and retrying from the beginning. Without being able to change the library's code, is it possible to retry the last item in the stream, so the http request can be retried again and the download can continue from there?
I realize this is probably impossible since the library's state would need to somehow be rewinded to before the error occurred. But maybe someone has a suggestion for how I can handle library errors like these that might happen many minutes into downloading a large file, and take advantage of the fact that I already have all the data successfully downloaded up to the point of the error.
In my app which uses AFNetworking/NSURLConnection for sending requests to the server I sometimes (very rarely) see this error in operation failure block:
Error Domain=NSPOSIXErrorDomain Code=9 "The operation couldn’t be completed. Bad file descriptor"
At https://devforums.apple.com/message/278770#278770 there's an answer to a similar question:
It means that someone has been deallocating file descriptors out from underneath NSURLConnection.
But in my own code I don't touch any streams of file descriptors in any way. It's just simple GET/POST requests.
What could be the cause of this problem?
Has someone encountered this error in their AFNetworking operations?
Also, how can I close this file descriptor deliberately if I really wanted to? The answer to this question will help me to understand the problem better.
According to this Apple TechNote on multitasking and networking, you can get EBADF (POSIX error 9) if the app is suspended and the socket is reclaimed.
Note: When your app resumes execution the actual error returned by a
socket's whose resources have been reclaimed is purposely not
specified here to allow for future refinements. However, in many cases
the error will be EBADF, which is probably not what you were
expecting! Under normal circumstances EBADF means that the app has
passed an invalid file descriptor to a system call. However, in the
case of a socket whose resources have been reclaimed, it does not mean
that the file descriptor was invalid, just that the socket is no
longer usable.
(I don't think this is a complete answer, but I'm hoping it will be helpful and can be turned into one.)
The error you're looking at it EBADF. It's returned from operating with a closed file. But you've figured this out already. :)
Assuming you're not using the stdio library, I think what you're running into is the equivalent of an overrelease. Basically, you're handing off ownership of a file to something, which is then closing it.
You should be paying particular attention to NSFileHandle, especially to see if you or anyone is calling initWithFileDescriptor:, copying a file, etc. These could cause the NSFileHandle to take ownership of the file descriptor, which means closing it when it's deallocated.
Look less at your networking code, and more at how you're setting up the files.
I am getting intermittent 500 errors when hitting the YouTube ContentID/partner API. At times, this is the response:
{"errors":[{"domain":"youtubePartner","reason":"internalError","message":"An internal error has occurred."}],"code":500,"message":"An internal error has occurred."}
At other times, this is the response
{"code":500,"message":null}
And at other times, the request succeeds.
This is happening most often when inserting a claim, next most often when setting ownership and, less often but still happening, when creating an asset and when setting advertising options.
Is there any alternative to adding retry logic?
There are most likely transient errors, you can just implement an exponential backoff retry policy and that would do best for now.
On the other hand, issue should've been fixed by now.
I'm using ASINetworkQueue to execute multiple ASIHTTPRequests, and if any request fails I'd like the queue to cancel any pending requests and end. From reading the docs this should be the default behaviour. But I'm finding that even after a request fails, I still get 'requestStarted' for most of the remaining requests, and 'requestFailed' for all of them - is this how it is supposed to be? I'm guessing it's maybe because my requests are quite small and the requests start before it has chance to cancel them once a failure is detected. I tried implicitly setting setShouldCancelAllRequestsOnFailure:YES but this made no difference.
Without knowing the exact nature of your requests ... short answer: Yes, it's working how it's supposed to. Your requests are starting before a failure occurs. Longer answer: Try setting the queue's maxConcurrentOperationCount property. This may help you control the request pipeline a bit better if you need to test for failure.
I have an app on the appStore that syncs xml data to a webservice. I've had two error reports today caused by the xml document ending prematurely. One ended right in the middle of an xml tag, so I know it isn't a problem caused by special characters. One of the errors occurred at 184kb, the other at 302kb, so it's not a problem with the request being truncated after so many bytes. It does seem to only be a problem on longer requests though.
Are there any specific settings that will prevent this truncation from happening?
I've been able to reproduce this by shutting down my app before the NSURLConnection finishes sending the request. I'm guessing the same thing was happening with a couple of my app users.