RHq-Metrics Use cases ( was Re: No concept of a platform? )

Heiko Braun ike.braun at googlemail.com
Wed Jan 14 16:30:43 UTC 2015


> On 14 Jan 2015, at 17:18, John Sanda <jsanda at redhat.com> wrote:
> 
>> 
>> On Jan 14, 2015, at 10:38 AM, Heiko Braun <ike.braun at googlemail.com <mailto:ike.braun at googlemail.com>> wrote:
>> 
>> 
>>> On 14 Jan 2015, at 14:57, Heiko W.Rupp <hrupp at redhat.com <mailto:hrupp at 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 at lists.fedorahosted.org <mailto:rhq-devel at 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 at lists.fedorahosted.org <mailto:rhq-devel at lists.fedorahosted.org>
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel <https://lists.fedorahosted.org/mailman/listinfo/rhq-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20150114/ba0e4ac6/attachment.html>


More information about the rhq-devel mailing list