6:22 a.m.
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)
* no polling = no wasting with resources
* cool demos
cons:
* switching the persona needs to be handled, but it's doable
What do you think?
jk
6:43 a.m.
----- 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
8:42 a.m.
| on the contrary alerts are sent
| inmediately via the actions architecture via configured transport
notifications are quite ok, but notifications on the dashboard in web UI are quite common
today (take social networks for instance)
Lucas, do you also send the notification on the bus if the alert is triggered?
| In a first thought, having a real full duplex communication is attractive.
well, we have the full duplex communication right now. Web Sockets are by design
full-duplex comm layer. What I was suggesting was to extend the set of use-cases we are
using it for, currently (afaik) it's only invoking commands.
| 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.
jk
9:01 a.m.
----- Original Message -----
From: "Jiri Kremser" <jkremser(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, October 21, 2015 3:42:41 PM
Subject: Re: [Hawkular-dev] cmdgw forwarding messages from bus to UI
| on the contrary alerts are sent
| inmediately via the actions architecture via configured transport
notifications are quite ok, but notifications on the dashboard in web UI are
quite common today (take social networks for instance)
Lucas, do you also send the notification on the bus if the alert is
triggered?
There are notifications showed in the UI today, but using the general polling mechanism
used for communication UI vs REST API.
Bus is used internally as a mechanism of communication between the alerts engine and its
plugins architecture.
| In a first thought, having a real full duplex communication is attractive.
well, we have the full duplex communication right now. Web Sockets are by
design full-duplex comm layer. What I was suggesting was to extend the set
of use-cases we are using it for, currently (afaik) it's only invoking
commands.
I guess this could be an interesting topic for a watercooler meeting.
It would be interesting how is it designed.
So, if at some point we need to apply a similar design, we can just reuse/adapt it.
Thanks,
Lucas
9:31 a.m.
| 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.
3321
days inactive
3322
days old
4 comments
3 participants
participants (3)
-
Jiri Kremser -
John Mazzitelli -
Lucas Ponce