rccreswell
commented
3 years ago I no longer suspect a cache problem.
On heroku, gunicorn creates multiple worker processes. Memory is not shared and each worker ends up with its own unique instance of the IncidenceNumberSimulationApp object. Successive HTTP requests are handled by potentially different workers, causing intermittent flipping between different IncidenceNumberSimulationApp instances. This explains the undesirable behavior recently observed---namely, random switching between uploaded data and the default French flu data, and random appearance and disappearance of previously generated simulation trajectories.
As of #97, slider value updates look at the simulator and current_df stored as attributes of the app object in order to repopulate the figure after purging outdated simulations. Hence this problem has become apparent now.
The correct way to save data is not merely to set an attribute of an object in server RAM, but to use something like a web database, cookie, flask session, or the user's browser (e.g., invisible JSON). Any of these correctly implemented will also fix #100; all require a fairly extensive update to the callbacks and app code.
Forcing the server to use just one process skirts the problem but cannot be considered a permanent solution, particularly in light of #100 and who knows what other problems we are likely to encounter.
Fix the problem with server side caching in heroku deployment.