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
[2] 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.