| But, dealing with session on server also mean an extra complexity
where the
| tradeoff is not trivial IMO.
agreed, the current approach is quite naive. It's the in-memory hashmap. This
works for 1 instance of Hawkular, but won't probably work for multi-node
deployments, on the other hand I see bigger challenges that are blocking the
multi-node Hawkular right now than this.
The WebSocket stuff that cmdgw has fully supports multi-node Hawkular servers. In fact,
the demo I showed a month or two ago illustrated this (though it was in the one direction
of UI->agent, not the other way around).
The way it works is each WS client (be it a UI client or a feed) connects to one hawkular
server in the cluster - call it H. As soon as a WS client connects to H, H will add all
the appropriate bus subscriptions for that client so when a message destined for that UI
client is received on the bus, the message is immediately forwarded over the WS to the
client. Now, if Hawkular Server X wants to send a message to that UI client, it does so
via the bus. It sends a message to a queue or topic which H can consume and forward to the
UI client over the WS.
The whole reason behind using the bus in the WebSocket stuff was to support multi-node
Hawkular Server deployments.