On Jan 14, 2015, at 10:38 AM, Heiko Braun <ike.braun@googlemail.com> wrote:


On 14 Jan 2015, at 14:57, Heiko W.Rupp <hrupp@redhat.com> wrote:

I see the following use cases for rhq-metrics in itself and a larger context:

1)  embedded usage in WildFly console (standalone)


the memory storage doesn’t work in domain mode so it’s not an option

There have been some discussions recently around whether or not we need/want to support an in-memory backend. The primary use case was for standalone. There are obviously fewer dependencies than when using an external data store.  Domain mode would require the Cassandra backend. Would you prefer embedding Cassandra via the cassandra subsystem instead of using the in-memory backend?



1b) like the above, but if people are happy to accept longer startup, it is using an embedded C*
 server that follows the WildFly lifecycle


yes, that’s what the cassandra subsystem does (talking about the subsystem,not the rhq C* EAR deployment)

After some investigation last week and some helpful explanations and demos from mazz, I better understand that the cassandra subsystem is the best, most appropriate way to embed Cassandra. It has not been clear whether or not embedding Cassandra would be a viable deployment option. If it is, then I think we should get rid of the C* EAR deployment and start focusing more on the subsystem.



2) embedded usage in WildFly console but with external RHQ-Metrics Server


already supported through the monitor subsystem, but lacks the (necessary) out-of-the-box experience.


1b) is what I want. but two things prevent this:

- unclear multi-node behaviour/constraints
- the rhq UI depends on jaxrs, which prevents embedding it

I have started a discussion on multi-node architecture at https://developer.jboss.org/thread/251536. Could you share thoughts/concerns with respect to domain mode in that thread?

As for the UI and JAX-RS dependency, undertow is available in WF core, and it supports servlets and web sockets out of the box right? To eliminate the JAX-RS dependency, couldn’t we either 1) implement the REST endpoints directly in servlet code ourselves or 2) expose a web sockets API that the UI uses? My preference would be web sockets instead of trying to implement a bunch of stuff that we get with JAX-RS.


/heikob
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel