Conversation
|
Looks like This is probably because in Foundation, In the meantime we should be able to keep track of whether we're using the shared session or not, and just avoid calling the function if so. |
|
Can you raise an SR for |
|
Can we use |
|
I have added a check to see if we are using a shared session before calling |
|
The travis tests for this PR are currently failing due to the API key for the external endpoints no longer being considered valid. This has been raised previously in issue #55. |
This pull request fixes the memory leak caused by creating multiple URLSessions when making requests. There are three cases where URLSession holds on to memory:
When creating a URLSession, Every session will create an SSL cache associated to your app, which takes 10 minutes to clear, regardless of it you clear the session. For this reason you are not intended to create a new session for each request. For requests without a delegate, I have fixed this by using URLSession.shared. This uses a shared singleton session for all the requests.
When creating a URLSession with a delegate:
"The session object keeps a strong reference to the delegate until your app exits or explicitly invalidates the session. If you do not invalidate the session by calling the invalidateAndCancel() or finishTasksAndInvalidate() method, your app leaks memory until it exits."
To solve this I have added a call to the session finishTasksAndInvalidate() to the RestRequest deinitialiser. (For URLSession.shared, this call doesn't do anything)
When using Circuit Breaker, The rest request is never deallocated .
As raises in issue RestRequest not deallocating #59, When you use a CircuitBreaker in the RestRequest references circuit breaker that references handleInvocation that references the request meaning it isn't deallocated. This Leak will be address in a future PR.