This thread precipitated some conversations off list with Heiko Braun about
wildfly-cassandra[1], wildfly-monitor[2], and the overall integration of rhq-metrics in
WildFly. Here is a brief summary.
Any server that wants to be monitored will run wildfly-monitor. rhq-metrics and/or
Cassandra could be co-located or run in their own dedicated vm’s, possibly even outside
the topology (hosted offering). This means that wildfly-monitor will require some form of
inter-process communication with rhq-metrics.
wildfly-cassandra can potentially run on any server, including domain and host
controllers. For production scenarios though, it it more likely that Cassandra would run
in its own dedicated VM. Regardless of how/where Cassandra is run, the metrics
functionality needs to exist in both scenarios out of the box.
With respect to standalone mode, embedded Cassandra, and the in-memory data store, the
preference is to use wildfly-cassandra in order to provide the same experience for both
standalone and domain modes. If we run into challenges with start up time or anything else
related to embedding Cassandra, we will assess and determine the best course of action.
The big problem with integrating rhq-metrics UI into the management console is the
dependency on JAX-RS. Other AngularJS applications are already integrated into the
console, so AngularJS itself should not be an issue. Iframes or Application Switcher might
be options for integrating the UI bits.
I previously mentioned a websockets API in this thread for a couple reasons. Undertow
core, which is in WF Core, provides websockets support. I was thinking that we pretty much
need to look at what WF Core provides and work with that. Undertow is a full blown HTTP
server, so we could still implement REST endpoints. It just doesn’t seem to make a lot of
sense to reimplement a lot of the logic we already get with JAX-RS. Hence my suggestion
for websockets.
Let me reiterate to be clear, I am not proposing that we get rid of the REST API. I am
only thinking about the embedded WF use case, which could very well be applicable to other
embedding scenarios. In terms of integration, it is better to approach it as follows.
rhq-metrics request a socket binding from WF and does what it needs to. This opens up the
possibility to Netty for example, which has no external dependencies (Other than the JRE)
and offers a lot more in terms of protocols than Undertow core.
[1]
https://github.com/rhq-project/wildfly-cassandra
<
https://github.com/rhq-project/wildfly-cassandra>
[2]
https://github.com/rhq-project/wildfly-monitor
<
https://github.com/rhq-project/wildfly-monitor>
A few questions occurred to me after sending out the above summary.
1) Do we look for an alternative, lightweight (i.e., minimal dependencies) REST framework
so that the WildFly management console can use rhq-metrics UI components?
2) Or should we leave the existing REST endpoints as is, implement a websockets API, and
update the UI components so that they can also work with the websockets API? Implementing
a websockets API assumes minimal dependencies. If need as many dependencies as we have
with the current REST endpoints for example, then it wouldn’t make sense to go down this
path.
3) With respect to wildfly-monitor, what is the best way to consume data? wildly-monitor
currently forwards data to an external instance of rhq-metrics using the REST endpoints.
It is possible though that rhq-metrics is a stand alone server, embedded in a different WF
server, or co-located in the same WF server. In the latter two cases, using the REST
endpoints might be problematic due to the JAX-RS dependency.