On 08 Jan 2015, at 19:17, John Sanda <jsanda(a)redhat.com>
wrote:
What do you think about deploying rhq-metrics as a WF extension?
This is my ultimate goal and the reason for many of my questions. In order to leverage
rhq-metrics in wildfly, it’s needs to be properly integrated and have a reasonable
out-of-the-box experience.
Some of my contributions (wildfly-monitor, cassandra-subsystem) have been intended to
provide the pre-requisites to further integrate rhq-metrics.
However we face some challenges to fully integrate rhq-metrics as a wildfly extension,
including the corresponding subsystems:
a) Support for domain mode
To support the wildfly domain mode, we need to know how the metrics components are
intended to be used in multi node environment (aka several vm’s operating as a whole)
It’s unclear to what degree the data partitioning and retention rules apply to such an
environment. The question is true for other jobs that require some level of coordination
(i.e. processing rollups).
IMO this is the biggest gap at the moment: these requirements are unclear/undefined and
all examples currently assume a single, standalone wildfly instance.
b) API and service dependencies
Integration on the level of a wildfly extension comes with a lot of constraints. Most
notable the availability of certain API’s and service at this level. Most of rhq-metrics
components assume the availability of a full EE7 stack and it’s API’s. We can certainly
discuss an extension of the low level API’s that wildfly provides to certain degree, but
it will never provide the full EE7 API for extensions.
At the moment this is a real blocker to further integrate rhq-metrics. There are ways to
circumvent these problems, but only by providing dedicated implementations of some
rhq-metrics-core API’s. This effectively prevents re-use and would put us in a position of
having to catch up with the latest functional enhancements.
Regards, HeikoB