<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 08 Jan 2015, at 19:17, John Sanda &lt;<a href="mailto:jsanda@redhat.com" class="">jsanda@redhat.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">What do you think about deploying rhq-metrics as a WF extension?<span class="Apple-converted-space">&nbsp;</span></span></div></blockquote></div><br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Some of my contributions (wildfly-monitor, cassandra-subsystem) have been intended to provide the pre-requisites to further integrate rhq-metrics.&nbsp;</div><div class=""><br class=""></div><div class="">However we face some challenges to fully integrate rhq-metrics as a wildfly extension, including the corresponding subsystems:</div><div class=""><br class=""></div><div class="">a) Support for domain mode</div><div class=""><br class=""></div><div class="">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)</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">IMO this is the biggest gap at the moment: these requirements are unclear/undefined and all examples currently assume a single, standalone wildfly instance.</div><div class="">&nbsp;</div><div class=""><br class=""></div><div class="">b) API and service dependencies</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Regards, HeikoB</div></body></html>