I didn't end up getting a response to this one, so I did my own research.
What seems to be happening as folks add websockets to distributed servers, is that they are using a gateway/proxy/loadbalancer that is websocket aware in some way. The point to point TCP websocket connection is between the clients and this facade. The facade is knowledgeable about the nodes in the cluster and where the server side of the application is running, and knows how to insulate its active clients from a node failover.
Since in this setting we are likely to be running inside an EE container, this kind of failover is mostly transparent to the server side developer, but not totally. So I'd suggest the websocket spec use the guidelines of EE web applications that are 'distributable' for applications deployed on distributed web servers. This places some programming restrictions on web components which allows distributed web containers to replicate a running session on a different node in the cluster should one node fail.
So I think that means websocket applications that are 'distributable' should not
- use static variables or local filesystems to store application state (use a database instead)
- put non Serializable data in websocket Sessions
Let me know if you have more things you think the specification should define for deployments on distributed servers.
10/24/12 6:16 PM, Danny Coward wrote:
" type="cite"> Hello websocket experts,
[jsr356-users] [jsr356-experts] Summary: Web Socket Sessions in Distributed Servers