search

dollabs / planviz

Planning Network Visualization
Apache License 2.0
14 stars 4 forks source link

HTN and TPN views shift when left alone #57

Closed pmdoll closed 7 years ago

pmdoll commented 7 years ago

Looking at attached pics, you will notice that in one of the pics, HTN is not centered as in the other one. This happens approximately 3 minutes after the views have been loaded and left alone. i.e Just load the views and let them sit for 3 minutes. At around 3 minutes time mark, you will notice that one or both, HTN and/or TPN views, has shifted in some direction.

screen shot 2017-02-19 at 4 26 28 pm screen shot 2017-02-19 at 4 22 26 pm

tmarble commented 7 years ago

I was able to reproduce this exactly once by setting up the left window to show the TPN and the right window to show the HTN. The HTN started as centered (lower image) and shifted after 3 minutes (upper image).

I've traced this to a part of the code that is trying to load-plans and one of those load operations times out. The symptom is you will see a message in the JavaScript console like: unable to show :v1.tpn app.js:82:216

I have not been able to reproduce it since in a single or dual window run. If you can provide the exact steps you took (when you loaded each window, what commands did you issue when the "ready" message appears, did you wait for one window to finish before executing a command in the other window)?

FWIW the length of the timeout is specified in secs (* 3 60 1000) in actions.cljs:1170

pmdoll commented 7 years ago

When a window is loaded, hold down alt/option key and in quick succession press right arrow key twice. This should load TPN view and then wait for 3 minutes.

tmarble commented 7 years ago

"I am curious to know what is the cause of this issue and a suggestion for a potential fix before we actually fix it."

Entering the right arrow key in rapid succession will call #'next-plan which, in turn, will call #'load-plan. This will start two asynchronous "threads". Likely the interleaved plan parts received from the server cause the values in {:keys [loaded? n-keys parts n-parts]} (st/app-get-plan plan-id) to be mutated in a conflicting way, causing one of the #'load-plan invocations to fail with the 3 minute timeout. This results in a call to #'display-plan which re-adjusts the positioning of the graph.

A potential fix is to have an atom holding the state of pending server transactions which will queue actions and only start the Nth action when the N-1th action has completed.