websocket/model server issues

[hhuuggoo]

This is a collection of issues with our current implementation of websockets. I'm putting this in one place because we had discussed moving from gevent to tornado

Current Issues

• We've made some choices based on how backbone does things. Backbone expects that when you push a model to the server, the response contains the servers view of what that model is. That's kind of ok - except that since we have a reactive object graph, that update might include more than just that one model. Currently this is how this works:
  • we respond with the servers representation to that model
  • Over the websocket channel, we push all the other changed models
  • Over the websocket channel, we push all changed models to any other clients that are listening This is kind of a bug, my view is that all models that are changed should be pushed as an atomic operation. So we can either
  • put all changed models into the ajax response
  • send nothing over the ajax response and push out all changed models over the websocket connection
• Continuum-ClientID is expected to be set which tells us who is sending the update. That somehow is no longer being set
• We're not properly synchronizing our websocket output, this can cause socket errors. If we receive 2 ajax requests that push data out to the same channel, and the second one tries to push data out while the first request is still pushing data, then we get problems
• Aside from py3 support, the tornado websocket server seem to be better because it works inside the QWebWindow (I think.. at least spyder can embed the notebook in QWebWindow so it must work)
• Our websocket model currently limits us from running bokeh on multiple processes. I propose the following
  • rip out the websocket part into a separate Tornado service
  • we support 2 configurations. For shelve/in memory backends, we run the websocket service in memory, and the main webserver just pushes data over a thread queue to the tornado service which sends it down the websocket channel.
  • For redis backends, we use redis pub/sub to push data out to tornado websocket clients. These will be run in a separate process. through some configuration, the main bokeh server will have to know which websocket services are around and encode that URL in talking to the bokeh clients. For simplicity, currently we can limit the number of websocket services to 1. The websocket server will probably run on a different port which means we will need to handle cross domain issues. Using alternate ports is also not good for the enterprise, however I don't see a good work around. Probably this will be handled with HAProxy/nginx/node web proxy anyways
  • We could do zmq instead of redis for the pub sub channel, this would enable us to have more similarity between the shelve/in memory/redis solutions. ZMQ is an ok dependency at this point since ipython requires it

[bryevdv]

I agree zmq is an ok as an optional dependency for the server.

[hhuuggoo]

well if it's an optional dependency than i don't htink it buys us much, as we will still need 2 implementations. In that case I think we should either use redis and limit the shelve/in memory backends to single process servers

[bryevdv]

No I just mean optional for people that don't use the server at all, sorry.

Edit: or another way, it's required if you use the server at all

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.