[BUG] when using nginx in front of multiple bokeh server instances, an app may be loaded multiple times
See original GitHub issueFOLLOW THESE INSTRUCTIONS CAREFULLY
ISSUES THAT DO NOT CONTAIN NECESSARY INFORMATION MAY BE CLOSED, IMMEDIATELY
The issue tracker is NOT the place for general support. For questions and technical assistance, come join the Bokeh Project Discourse.
For defects or deficiencies, please provide ALL OF THE FOLLOWING:
ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
bokeh server version: 1.1.0 python version: 3.6.6
Description of expected behavior and the observed behavior
I have deployed a number of jpython notebooks that I load through a standalone bokeh server application. I run multiple instance of the bokeh server with nginx in front. Frequently, when I load one of the notebooks via an http call, the python code runs more than once. The expectation is that it will only run once. Running twice adds a performance hit, even though it eventually does work.
After discussion with @bryevdv at https://discourse.bokeh.org/t/using-standalone-bokeh-server-to-display-jupyter-notebooks-that-contains-some-holoview-objects/4015/6 , it seems this is a known issue.
Complete, minimal, self-contained example code that reproduces the issue
# code goes here between backticks
Stack traceback and/or browser JavaScript console output
Screenshots or screencasts of the bug in action
Issue Analytics
- State:
- Created 4 years ago
- Comments:12 (7 by maintainers)
Top GitHub Comments
@chris-ratcliffe Thank you for running the experiment. Unless Tornado itself offers some solution for sticky sessions with
--num-procs
then there is probably nothing that can be done in that case. I will look in to that, but at a minimum will use this issue to clearly document the state of affairs and what can be expected in various configurations, e.g how this can be avoided with nginx.Just thinking out loud but another possible approach is to set some sort of testable condition that could be used to distinguish between “running in the HTTP request” vs “really running in the WS handler” Then app code could skip anything that does real work in the HTTP request run… that would be pretty ugly but at least provide an avenue for when optimizing this is important.