missioncommand / emp3-web

Extensible Map Platform (EMP) web development kit
Other
19 stars 9 forks source link

Map.onSuccess not working properly #326

Closed sjpinizzotto closed 7 years ago

sjpinizzotto commented 7 years ago

Map.onSuccess callback is called, but then the map goes back into an initializing state. While it is in this initializing state, the Map methods do not work. Then the map swaps back to ready after the engine correctly reports the readiness. During that period of swapping between ready, initializing, and ready again, map calls are failing as the map is indicating it is not ready, even though the onSuccess is called.

michael-spinelli commented 7 years ago

is this a leaflet or core issue?

sjpinizzotto commented 7 years ago

this is core issue.

alberto-acevedo commented 7 years ago

I tested the development branch and the emp.map.status (line 1434) sequence I was getting when starting a new map is as follows:

idle init ready

When doing a map swap the status sequence is as follows:

ready mapswappinginprogress ready

I was not able to see the bad sequence:

ready initializing ready

Do you have a script that could replicate the issue? Under what circumstances were you getting the bad sequence?

alberto-acevedo commented 7 years ago

I was able to see the issue. It is a timing issue. The API and core have their own property for map status. When the AP.Map is created the status is immediately set to 'ready' (assuming by design). For the case of the core the setting of the status from 'idle' to 'initialization' is happening in a non synchronized mode inside a timeout located in the emp.instanceManager/buildInstance function. The api map finish its initialization without waiting for the engine to be ready (assuming it is by design) and calls the map.onSuccess. While overlays and features are added inside the map.onSuccess, requests are sent to core map transaction queue until the engine sends the map status of 'ready'. Nothing is rendered on the map until the engine sends the ready status. while this process of the client sending overlays and features happens, there is no initialization status synchronization with the core map and the status could change from ''ready' or 'idle' to 'initialization' in the middle of the of the API processing requests. When the status is changed to 'initialization', all requests are queued again giving the impression that the map is failing to render the overlays and respective features. I propose setting the core map status to 'initialization' outside of the timeout to keep the process and status in synch. Cesium is also sending the ready status in a non synchronize mode to complicate things. The fix will prevent the case of a 'ready' status changing to 'initialization' status.

Below is the sample script that creates a Cesium map, creates an overlay, several features are added to the overlay, and a loop is execute to hide /unhide features on the map. All the rendering is called from within the map.onSuccess.

Use branch 326.

The test is successful if features are rendered on the map and then they keep hiding/unhiding continuously.

Unzip the following file and paste into your tomcat server webApps/emp3-map folder.

testOnSuccessMapCore.zip

alberto-acevedo commented 7 years ago

Mike, please review the fix in the core.

michael-spinelli commented 7 years ago

Looks good

mubinakhan commented 7 years ago

reintegrate

alberto-acevedo commented 7 years ago

Merged into the dev branch. Closing this issue.