Every 11th execution of NSURLSessionTask takes much longer than others - ios

Question

I'm having a strange behavior in my Swift app, that I currently don't understand.
I have subclassed NSOperation to create different operations that can call Rest-WebServices via NSURLSession / NSURLSessionTask. This works fine in general.
In my case I have to execute many of these operations successively. Let's say I create a "chain" of 30 NSOperations with setting dependencies to execute them one by one.
Now I could reproduce the behavior, that every 11th (?!) execution of such an operation, takes much longer than the others. It seems as if the execution "sleeps" for nearly 10 seconds before it goes on. I can rule out, that the concrete web service call is the issue. Because if I change the order of execution, it is still the 11th operation that "hangs".
Currently I am creating a new instance of NSURLSession (defaultConfiguration) during the execution of every operation. Yesterday I tried to create a static instance of NSURLSession and create the instances of NSURLSessionTask during execution only. And now the "hanger" is gone! Unfortunately I could not do it this way, because the NSURLSessionDelegate has to be different for some operations, but this delegate must be passed during initialization.
Did anyone experience a similar behavior?
First I thought my code is too complex to post. But after Ketans comment, I will give it a try. I have trimmed it down to the most important parts. I hope this helps to show my problem. If you need more detail, please let me know.
class AbstractWebServiceOperation: NSOperation {
// VARIANT 2: Create a static NSURLSession only once --> The "sleep" DOES NOT occur!
static let SESSION = NSURLSession(configuration: NSURLSessionConfiguration.defaultSessionConfiguration())
init(servicePath:String, httpMethod:String) {
// This is an 'abstract' class, that will be subclassed for concrete webService calls that differ in servicePath for URL, HTTP Method and parameters
}
// Override start() function of NSOperation to do webService call. NSOperations vars (ready, executing, finished) are overridden too, to get NSOperation "waiting" for the webService result. But I don't think it is relevant for the issue. So I did leave it out.
override func start() {
super.start()
// [...]
if let request = createRequest()
{
let task = createTask(request)
task.resume()
}
// [...]
}
// Creates the concrete NSURLRequest by using the service path and HTTP method defined by the concrete subclass.
private func createRequest()-> NSMutableURLRequest? {
// [...]
let webServiceURL = "https://\(self.servicePath)"
let url = NSURL(string: webServiceURL)
let request = NSMutableURLRequest(URL: url!)
request.timeoutInterval = 60
request.HTTPMethod = self.httpMethod
request.addValue("application/json;charset=UTF-8", forHTTPHeaderField: "Content-Type")
request.addValue("application/json;charset=UTF-8", forHTTPHeaderField: "Accept")
return request;
}
// Creates the concrete NSURLSessionTask for the given NSURLRequest (using a completionHandler defined by getCompletionHandler())
func createTask(request:NSURLRequest) -> NSURLSessionTask
{
// VARIANT 1: Create a new NSURLSession every time a AbstractWebServiceOperation is executed --> The "sleep" occurs!
let session = NSURLSession(configuration: NSURLSessionConfiguration.defaultSessionConfiguration(), delegate: nil, delegateQueue: nil)
return session.dataTaskWithRequest(request, completionHandler:getCompletionHandler())
// VARIANT 2: Create a static NSURLSession only once --> The "sleep" DOES NOT occur!
return AbstractWebServiceOperation.SESSION.dataTaskWithRequest(request, completionHandler:getCompletionHandler())
}
// Returns the completion handler for the NSURLSessionTask (may be overriden in subclass)
func getCompletionHandler() -> (NSData?, NSURLResponse?, NSError?) -> Void
{
return completionHandler
}
// Default completion handler
lazy var completionHandler:(NSData?, NSURLResponse?, NSError?) -> Void = {(data : NSData?, response : NSURLResponse?, error : NSError?) in
// default completion handling
}
}

Answer 1

Awww... I simply forgot to call session.finishTasksAndInvalidate() to invalidate the session after my webService call is done.
That solves my problem!