GeoJSON tiles: Stopping the MapWorkerPool in TileRendererLayer.onDestroy() to avoid crash

[nickw]

Hi,

About 6 months ago I brought up an issue with a MapDataStore which returns GeoJSON (to allow retrieval and rendering of an online or offline GeoJSON tile source with Mapsforge). This would have been early June; for personal reasons I had to abandon this issue at the time.

I mentioned at the time that on occasion an issue similar to Issue 957 was produced on shutdown, probably because the MapWorkerPool threads to render data were still running after the activity has been destroyed and all the bitmaps had been destroyed.

Have looked at the Mapsforge source in more detail and had a couple of questions related to things which  _might_ solve the problem. Since the issue comes up only rarely, it's difficult to test, so I thought I'd bring up the possible solutions here:

- It looks like I can safely return null in readMapData() in MapDataStore, with the result that this tile will not be rendered (without crashing). Thus I could override close() in my custom MapDataStore subclass to facilitate this.

- stopping the MapWorkerPool looks another option. Could I safely override onDestroy() in TileRendererLayer to stop() the MapWorkerPool (this appears currently not to be done)?

Thanks,
Nick

[Emux]

> allow retrieval and rendering of an online or offline GeoJSON tile source with Mapsforge

That would be a nice addition. :)

Hint: VTM already supports GeoJSON vector tiles.

> It looks like I can safely return null in readMapData() in MapDataStore

We already return null in some cases, and you could return an empty map read result too depending your implementation.

> Could I safely override onDestroy() in TileRendererLayer to stop() the MapWorkerPool (this appears currently not to be done)?

At exit the MapView.destroyAll is called where there is removal of all layers.
And TileRendererLayer.onRemove is triggered which contains the MapWorkerPool.stop.

--
Emux

[nickw]

Hi, thanks for that.

On implementing some logic to prevent the GeoJSON being read and processed after shutdown (by setting a boolean in the MapDataStore's close() method)  I unfortunately still seem to get the same "issue 957" error.

I also sometimes (not always) get an InterruptedException as well if that helps.

at java.lang.Object.wait

at org.mapsforge.map.view.FrameBufferHA.lockLMBitmap (line 88)

at org.mapsforge.map.view.FrameBufferHA.getDrawingBitmap (line 78)

at org.mapsforge.map.laer.LayerManager.doWork (line 81)

at org.mapsforge.map.util.PausableThread.run (line 140)

The problem would seem to be that background threads are still trying to do work after the activity has been destroyed; any hints on how this could be resolved?

Maybe best use VTM but would be good if I can get this sorted with Mapsforge to save having to rewrite parts of my app.

Thanks,

Nick

[Emux]

Have you seen such issues with map files using the latest Mapsforge?

That's a public implementation which we all can test.
Have seen such rare harmless exception at close, without further impacts.

- Try using the new released FrameBufferHA2
(FrameBufferHA will be deprecated)

- Can test also the old non-HA FrameBuffer

- See the MapView.destroyAll and all its calls hierarchy. Do you follow the same procedure?

--
Emux

[nickw]

>Have you seen such issues with map files using the latest Mapsforge?

>That's a public implementation which we all can test.
>Have seen such rare harmless exception at close, without further impacts.

The problem did not arise with standard map files, even on 0.8.0; I tried that several months ago.

 

>- Try using the new released FrameBufferHA2
>(FrameBufferHA will be deprecated)

>- Can test also the old non-HA FrameBuffer

-> See the MapView.destroyAll and all its calls hierarchy. Do you follow the same procedure?

Thanks. I am now running against 0.9.0 and changed to FrameBufferHA2; however, I still get the same issue as before with "issue 957" if I destroy the app while the rendering threads are taking place.

I do call MapView.destroyAll() anyway.

That said, I have looked a bit at the API for VTM and that does seem to suit my use case quite nicely - so may well go with that.

Thanks,

Nick

[nickw]

On Tuesday, December 19, 2017 at 11:59:59 AM UTC, nickw wrote:

>Have you seen such issues with map files using the latest Mapsforge?

>That's a public implementation which we all can test.
>Have seen such rare harmless exception at close, without further impacts.

The problem did not arise with standard map files, even on 0.8.0; I tried that several months ago.

The native-level crash (not being a Java exception) is obviously difficult to deal with without impacting the user experience (as 'unfortunately the app has stopped' appears on shutdown).

[Emux]

> The problem did not arise with standard map files

If the issue does not happen with map files, but only with your GeoJSON implementation, then could need to debug / compare how the regular Mapsforge stops all its jobs when exit the app.

> if I destroy the app while the rendering threads are taking place

That's the case I've seen with map files, that while the whole map has NOT been filled, if exit the app then the exception can happen.
Would need to fix that, though have not seen any serious side effects from that (the exception is catched anyway - so no crash happens).

--
Emux