NSURLSessionConfiguration leaking

I have invalidated my NSURLSession object but the NSURLSessionConfiguration object still has not called dealloced.


Below is the main code

{

NSURLSessionConfiguration* sessionConfig = [NSURLSessionConfiguration ephemeralSessionConfiguration];

sessionConfig.timeoutIntervalForRequest = 2.0f;

sessionConfig.timeoutIntervalForResource = 2.0f;


NSURLSession* session = [NSURLSession sessionWithConfiguration:sessionConfig];


NSMutableURLRequest* request = [self requestURLString:URLString databody:nil requestMethod:@"GET" isjson:true];

NSURLSessionDataTask* dataTask = [urlSession dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {

NSInteger responseCode = [(NSHTTPURLResponse*)response statusCode];

if (error || responseCode != 200) {

failure(data,response,error,responseCode);

} else {

NSError *jsonError;

id JSON = [NSJSONSerialization

JSONObjectWithData:data

options:NSJSONReadingAllowFragments

error:&jsonError];

if (!jsonError) {

success(JSON,response,error);

} else {

failure(data,response,error,responseCode);

}

}

}];

[dataTask resume];

[urlSession finishTasksAndInvalidate];

}


I have created a class extension for NSURLSessionConfiguration and NSURLSession that overrides dealloc is called, however it is not being called.


@interface NSURLSessionConfiguration(test)

-(void)dealloc;

@end

@implementation NSURLSessionConfiguration(test)

-(void)dealloc{

NSLog(@"zzzzzzzz NSURLSessionConfiguration deallocated");

}

@end



@interface NSURLSession(test)

-(void)dealloc;

@end

@implementation NSURLSession(test)

-(void)dealloc{

NSLog(@"zzzzzzzz NSURLSession deallocated");

}

@end


UPDATE*


apprently because i have



@interface NSURLSession(test)

-(void)dealloc;

@end

@implementation NSURLSession(test)

-(void)dealloc{

NSLog(@"zzzzzzzz NSURLSession deallocated");

}


@end

The NSURLSession dealloc seems to be overriding the NSURLSessionConfiguraiton dealloc. Does anyone know why?

Accepted Reply

I've been trying to find where its stated that we have only one urlsession per app.

Whoa, that’s not what I wrote. What I said was:

  • NSURLSession objects are intended to be long-lived.

  • A common usage pattern is to create a single session object at app launch and have it persist for the duration of the app.

  • Creating a new session object per request is needlessly inefficient.

All of these are true. None of these preclude you having multiple NSURLSessions within your app, and in some contexts that makes perfect sense. However, created and invalidate a session for every request is definitely not recommended.

The goal of the session API is for you to have a session for each logically distinct type of request. For example:

  • Different subsystems within your app might each use their own session to avoid any cross talk.

  • A web browser might use a separate session for each private browsing tab.

  • A mail app might have a separate session per account (so it can control things like the TLS version numbers).

  • You might use separate sessions to deal with multiple TLS identities (QA1727 TLS Session Cache has just been updated to mention this).

  • You might have a standard session for general work and a background session for large downloads.

All of these are perfectly fine examples of using multiple sessions in an app. OTOH, using a session per request is, as a I said, needlessly inefficient.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

I have created a class extension for NSURLSessionConfiguration and NSURLSession that overrides dealloc is called, however it is not being called.

That’s not a valid test. To cope with odd structuring requirements within the OS, NSURLSessionXxx objects are not straightforward Objective-C classes. You won’t be able to successfully subclass or extend them.

Is that the only evidence you have that something is leaking? Or are you seeing the leak in Instruments as well?

Finally, be aware that NSURLSession objects are intended to be long-lived. A common usage pattern is to create a single session object at app launch and have it persist for the duration of the app. Creating a new session object per request is needlessly inefficient. I’m not sure if you’re doing that for real or just to demonstrate this problem, but if it’s the former then I recommend that you change direction.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I've been trying to find where its stated that we have only one urlsession per app. Could you show where they state there should be only 1?

I've been trying to find where its stated that we have only one urlsession per app.

Whoa, that’s not what I wrote. What I said was:

  • NSURLSession objects are intended to be long-lived.

  • A common usage pattern is to create a single session object at app launch and have it persist for the duration of the app.

  • Creating a new session object per request is needlessly inefficient.

All of these are true. None of these preclude you having multiple NSURLSessions within your app, and in some contexts that makes perfect sense. However, created and invalidate a session for every request is definitely not recommended.

The goal of the session API is for you to have a session for each logically distinct type of request. For example:

  • Different subsystems within your app might each use their own session to avoid any cross talk.

  • A web browser might use a separate session for each private browsing tab.

  • A mail app might have a separate session per account (so it can control things like the TLS version numbers).

  • You might use separate sessions to deal with multiple TLS identities (QA1727 TLS Session Cache has just been updated to mention this).

  • You might have a standard session for general work and a background session for large downloads.

All of these are perfectly fine examples of using multiple sessions in an app. OTOH, using a session per request is, as a I said, needlessly inefficient.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks dude , that makes perfect sense.