RUMM-610 Hotfix for memory leaks on data upload #180
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What and why?
🐛 This hotfix is addressing #178 - where constantly growing memory usage is reported due to intensive logging.
With intensive logging comes frequent upload... and what I noticed is that every upload results with a memory leak. Here, allocations graph for 10 uploads (each batch was
~1MB
):How?
The reason of this leak, was an internal caching applied by the
URLSession
- by default, the session'sconfiguration.urlCache
is notnil
, which results with some representation of theURLRequest
being kept in memory (together with its.httpBody
):This started being visible after #65, where the
?batch_time=
query parameter was introduced and cache keys become unique for every new request.The fix is simple - we need to opt-out from using the
.urlCache
for theURLSession
. After this, the allocation graph is no longer growing infinitely (same 10 batches,~1MB
each - no more "Live" blobs):Review checklist