React-native-mapbox-gl: Offline caching results in memory termination

[timfpark]

I am attempting to cache a set of roughly 27 packs and am running into memory termination issues with the app.

Basically, it will start downloading the added packs and then fail with a memory termination:

2016-05-12 07:12:50.217 [info][tid:com.facebook.react.JavaScript] { countOfResourcesCompleted: 166,
countOfResourcesExpected: 1312,
name: '10_401_179',
countOfBytesCompleted: 12317243,
maximumResourcesExpected: 1312 }
2016-05-12 07:12:50.245 [info][tid:com.facebook.react.JavaScript] { countOfResourcesCompleted: 167,
countOfResourcesExpected: 1312,
name: '10_401_179',
countOfBytesCompleted: 12317300,
maximumResourcesExpected: 1312 }
2016-05-12 07:12:50.274 [info][tid:com.facebook.react.JavaScript] { countOfResourcesCompleted: 168,
countOfResourcesExpected: 1312,
name: '10_401_179',
countOfBytesCompleted: 12317357,
maximumResourcesExpected: 1312 }
2016-05-12 07:12:50.305 [info][tid:com.facebook.react.JavaScript] { countOfResourcesCompleted: 169,
countOfResourcesExpected: 1312,
name: '10_401_179',
countOfBytesCompleted: 12317414,
maximumResourcesExpected: 1312 }
2016-05-12 07:12:50.340 [info][tid:com.facebook.react.JavaScript] { countOfResourcesCompleted: 170,
countOfResourcesExpected: 1312,
name: '10_401_179',
countOfBytesCompleted: 12317471,
maximumResourcesExpected: 1312 }
Message from debugger: Terminated due to memory issue

[bsudekum]

@1ec5 have you seen this before?

[1ec5]

@bsudekum, does this component aggressively fetch progress info for every existing offline pack? If so, that's tantamount to opening every pack in memory, which will easily run into memory limits with all but the most trivial of offline packs.

[dapetcu21]

@1ec5 With the current getOfflinePacks API, yes it does. Do you think this should be changed in favour of letting the user manage resuming packs and requesting their progress (mirroring the native API more closely)?

[1ec5]

Yes, absolutely. While the current implementation of getOfflinePacks is very friendly to use, it makes it far too easy to cause hangs or out-of-memory conditions. This is an unfortunate consequence of the current design in the core Mapbox GL Native code. I originally took the same approach as this library in mapbox/mapbox-gl-native#4482 but had to revise it.

(One of the reasons it’s so expensive to determine the progress of a pack is that tiles and other resources are shared between any packs that need them. So in the database, a pack doesn’t actually “own” its resources to be able to enumerate them.)

[esamelson]

Are there any updates on this, or suggestions for where to begin fixing it? I'm still getting crashes caused by memory limits, and it's preventing me from using the offline functionality in my app.

[1ec5]

suggestions for where to begin fixing it

Remove this code that force-loads all offline packs at launch. That’s critical.

Then implement a way for the developer to request the progress of an individual offline pack’s progress and report it in a callback. Getting that callback to work is the tricky part, since there’s no completion handler in -[MGLOfflinePack requestProgress]. You’ll have to add a temporary KVO change observer, making sure to remove it once you’ve gotten the progress.

[DannyRussell]

I'm really looking forward to seeing this resolved so offline packs work reliably. Thanks!

[ddolheguy]

Yes please, offline maps are such an important feature and I'd really appreciate them fixed as well. Thanks :)