----- Original Message -----
From: "Jiri Kremser" <jkremser(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, October 20, 2015 1:22:06 PM
Subject: [Hawkular-dev] cmdgw forwarding messages from bus to UI
Hello,
when creating the topology graph, the nice feature would be to see the
newly added resources in inventory in a real-time. Currently, the approach
on many places in UI is polling with long intervals. Each 20 seconds the
url list, app server list or topology is updated with the fresh data.
We have the server-side bus in place into which inventory events when anyone
is 'CRUDing' the entities, I believe alerts are being sent there, etc. Also
we have the cmdgw module for dealing with the bus-agent-ui communication, it
uses the WebSockets for full-duplex comm. From what I've seen it works like
this:
1) ui initializes the WS connection
2) server stores the session, correlation id is the session id
3) later on ui invokes a command with some id
4) once the command is done the ui is notified by the server side (no
polling, real server push)
+ some magic with bus (bus works here as a glue with the other components)
What would be imho really useful would be not only using the web socket layer
for sending the responses on previously requested operations but also having
the ability to send the notification to whoever cares on the ui (without any
former explicit action in the ui). I mean events like "something bad
happened". After talking with Peter, the better correlation id here is the
tenant id, because we don't want to leak the information among the tenants.
So if the server keeps the info which session id was created for which
tenant we are almost there.
pros:
* alerts can be displayed immediately (no need to wait 20 seconds for the
refresh)
(Small disclaimer, about alerts, being displayed inmediately on the UI are not a strong
requeriment on that side, on the contrary alerts are sent inmediately via the actions
architecture via configured transport)
* no polling = no wasting with resources
* cool demos
cons:
* switching the persona needs to be handled, but it's doable
What do you think?
In a first thought, having a real full duplex communication is attractive.
But, dealing with session on server also mean an extra complexity where the tradeoff is
not trivial IMO.
I know that the "clustering-scalability" chapter is not formally open yet, but
my first thought is that we deal with a custom session mechanism on the server the
complexity might be increased (we need to use ISPN to share this state, to deal with
distributed scenarios, etc).
Also, there was a related topic some weeks ago about a server side component to do high
level integrations between components, Jay started to think about it, perhaps these two
topics can be related and on that scenario, having a full duplex communication could be
interesting.
Just my 2 cents.
jk
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev