On Jan 14, 2015, at 10:38 AM, Heiko Braun
<ike.braun(a)googlemail.com> wrote:
> On 14 Jan 2015, at 14:57, Heiko W.Rupp <hrupp(a)redhat.com
<mailto: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
<
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel