Releasing connections

[JohnCastle4]

We have developed a Cordova plugin for our mobile application and we are using the iOS library, we're also using the Android library, but the issue we found was on iOS. While investigation a performance issue, we found that GPKGConnection.queryWithDistinct gets a resultConnection, but doesn't release it. This resulted in the usedConnections continuously growing.
We're not able to push the changes back for company policy reasons, but we found releasing the Connection to be highly beneficial.
Thought I would raise it here in case there are other changes beyond the one that we are making address the specific issue we have found.

[bosborn]

Hello.

Yes, a GPKGResultSet returned from any method should/must be closed immediately when the results are no longer needed. A SQLite (read result) connection is pulled from the connection pool for the query and not released until the GPKGResultSet is closed. At the same time, that connection must remain open temporarily to access those results. Any method in this library that internally opens but does not return the result set, closes that connection before return (unless you found a bug where that is not the case). Any call to this library that is returned any type of Result Set becomes responsible for closing the results as part of normal and expected usage.

Unless I am misunderstanding this doesn't appear to be an issue within the library and upon closing all your query results there was no issue?

Edit: FYI on Android, any type of Cursor or CursorResults should also be closed to avoid issues.

[bosborn]

If it helps, we also use GPKGGeoPackageCache to manage multiple open GeoPackages.

Here are our iOS apps that use this library that can be referenced as examples

• MapCache [manager, cache, index]
• MAGE [manager, cache, index]
• Marlin [manager, cache, index, rtree]

[JohnCastle4]

Thanks, we are already GeoPackageCache

[JohnCastle4]

It's not data related, the section of map being retrieved isn't related to the crash. It looks like memory, the memory usage just keeps going up. I don't think it's our open layers implementation, this was pretty stable with SpatiaLite for many years. However, we've been forced to migrate away from that library because it's no longer being maintained and the world moves on. Suspect it's our code. We're doing a queryFeatures andBoundingBox and we are now closing the resultset. We pass in the map extents and convert those into a bounding box, then using PROJTransform and SFPGeometryTransform to convert that into a projected bounding box for the layer and that's our bounding box. It seems to work, but it appears not be releasing everything. It also could be our Cordova interface returning an array of the feature ids and geometry that's not handling memory well.

[bosborn]

If you are adding features on the map, we've had to remove features no longer visible in map view for performance. We prefer to use feature tile overlays (dynamically drawn tiles from features). See // Feature Tile Overlay (dynamically draw tiles from features) on the README example. Queries are still done from map "clicks". In both cases, we also simplify geometries to reduce the number of points in the displayed or drawn geometry.

[JohnCastle4]

Finally figured it out. Android was using the same GeoPackageManager instance as much as possible. Whereas iOS was getting a new one every time and opening a connection. I'm not very familiar with debugging in xCode, but once I found the memory management tools in the debugging the connection pool leak became obvious. Thank you for your help, much appreciated. The app is now much faster and doesn't leak. This discussion can be closed now.