On 14 Jan 2015, at 17:18, John Sanda <jsanda(a)redhat.com>
wrote:
>
> On Jan 14, 2015, at 10:38 AM, Heiko Braun <ike.braun(a)googlemail.com
<mailto:ike.braun@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?
yes, I would recommend using the cassandra subsystem for both standalone and domain mode.
Both models are working and described here:
https://github.com/rhq-project/wildfly-cassandra
<
https://github.com/rhq-project/wildfly-cassandra>
>
>>
>> 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.
The reason for the dependency on C* master (v3.0) are some patches that we did to support
the embedded execution. The version used within the EAR (v2.x) terminates the VM when
invalid configurations are detected (using System.exit())
I would recommend using C* master, unless there are good reason not to (i.e. CQL
incompatibilities, unclear roadmap, etc)
>
>
>> 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?
yes, will do.
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 <mailto:rhq-devel@lists.fedorahosted.org>
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
<
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org <mailto:rhq-devel@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
<
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel>