JBossDeveloper

Mike is right, the actual requirements are the key. To base this decision on the provided rest api's or any other implementation detail is rather short sighted and will come back to us in the long run.

Why do we need to pick a "container" at all? If i look at the potential clients of this project, they all bring their own specific runtime to the table: wildfly, fuse, etc. Doesn't it make more sense to build RHQ metrics as set of embeddable services that can adopt to the container specifics?

John Sanda wrote:

 

I am wondering about embedding rhq-metrics into X.

Thats an important question, but I think it will not be answered by chosing WF.Core versus Vert.x.  Both runtimes will make it difficult to embed rhq-metrics, depending on who you ask. Even if it's just the dependencies you have to pull in and maintain. What's more important are the contracts between core services  and adjacent systems as well as  the data model and protocols in use.

If this is done properly, then either WF or Vert.x can simply be considered a reference runtime. No matter what, somebody will have todo the integration with an alternative runtime anyway.

Heiko Braun schrieb:

 

Doesn't it make more sense to build RHQ metrics as set of embeddable services that can adopt to the container specifics?

This "being embeddable" is one of the key elements in my point of view, so you are right here. Otherwise we can not support the graphing for the WildFly console use case.

And then on the other hand we will need to provide a "default" container/runtime for the situation where the does not have any WildFly/Vert.x/... running and just wants to use rhq-metrics. Think of all those cases where rhq-metrics is supposed to replace some RRDB already in use. Or where the remaining monitoring system environment is written in C, Shell or Python.

While I fully agree that we need to define protocols etc. I am not sure if we should really completely abstract layers so to e.g. allow arbitrary rest-providers like a JAX-RS frontend oder a verticle, that then puts some data on some "bus" to forward that to the common "computing core"/middleware which then deals with the concrete backend in use (memory, "internal" C*, "external" C*).

I dont think we need to fully abstract all layers. But the contracts should be clearly exposed so that either side can be replaced, if needed. To stick with the REST example, this would be the contract that describes the ingestion of data. One side would be taking the data of the wire and passing it to the core services that do persistence, normalisation, etc. In this example ot should be possible to easily plug different REST libraries as well as different transports, like UDP for instance.

Obviously some contracts are more complex then others. So it might not make sense in all cases. For instance I wouldnt consider this for the data store, but simply declare C* as a prerequisite.

The reason why I mention it, is that systems like Vert.x, mix programming models and runtime/platform services in a way that requires us to be extra cautious. Having a default implementation based on vertx is fine, but if we fail to encupsulate the core sevices in a way that requires to you embed all of vertx (coupling) then it would be bad for integration with other runtimes, like WF.

Am 18.05.2014 um 10:40 schrieb Heiko Rupp <do-not-reply@jboss.com>:

 

 

JBoss Community

Runtime container choice. vert.x vs WF core vs Karaf vs ???

reply from Heiko Rupp in rhq-metrics - View the full discussion

 

Heiko Braun schrieb:

 

 

 

Doesn't it make more sense to build RHQ metrics as set of embeddable services that can adopt to the container specifics?

 

 

 

This "being embeddable" is one of the key elements in my point of view, so you are right here. Otherwise we can not support the graphing for the WildFly console use case.

 

 

 

And then on the other hand we will need to provide a "default" container/runtime for the situation where the does not have any WildFly/Vert.x/... running and just wants to use rhq-metrics. Think of all those cases where rhq-metrics is supposed to replace some RRDB already in use. Or where the remaining monitoring system environment is written in C, Shell or Python.

 

 

 

While I fully agree that we need to define protocols etc. I am not sure if we should really completely abstract layers so to e.g. allow arbitrary rest-providers like a JAX-RS frontend oder a verticle, that then puts some data on some "bus" to forward that to the common "computing core"/middleware which then deals with the concrete backend in use (memory, "internal" C, "external" C).

 

Reply to this message by going to Community

Start a new discussion in rhq-metrics at Community

Following rhq-metrics in these streams: Email Watches

Following Runtime container choice. vert.x vs WF core vs Karaf vs ??? in these streams: Inbox, Email Watches

Am 19.05.2014 um 10:04 schrieb Heiko Braun <do-not-reply@jboss.com>:

I dont think we need to fully abstract all layers. But the contracts should be clearly exposed so that either side can be replaced, if needed. To stick with the REST example, this would be the contract that describes the ingestion of data. One side would be taking the data of the wire and passing it to the core services that do persistence, normalisation, etc. In this example ot should be possible to easily plug different REST libraries as well as different transports, like UDP for instance.

Yes, exactly. And that also matches https://community.jboss.org/wiki/GeneralIdea  where a REST-api will be a default-service,

but where it will be possible to plugin in other apis to e.g. also ingest data from Ganglia etc.

 

Obviously some contracts are more complex then others. So it might not make sense in all cases. For instance I wouldnt consider this for the data store, but simply declare C* as a prerequisite.

While I do not ever want to use / support SQL databases here (myself), I think "hardcoding" C* may be bad too:

- embedding into Wfly to be able to use rhq-metrics graphs with a local (memory based) storage may not work, as C* seems to require always running in its own process, which may not be desired (to say it politely).

- If we program against C2.x we will have larger issues porting when C3.x is available with possibly different semantics for consistency or different more modern apis ( actually we already seem to require 2.x and won't work with 1.x)

The reason why I mention it, is that systems like Vert.x, mix programming models and runtime/platform services in a way that requires us to be extra cautious. Having a default implementation based on vertx is fine, but if we fail to encupsulate the core sevices in a way that requires to you embed all of vertx (coupling) then it would be bad for integration with other runtimes, like WF.

Yep. Especially as I do not see that we will be able to embedd vert.x inside e.g. WildFly.

If we aim for WF, then it would probably make sense to go straight for WF 9. the whole extension model has been drastically simplified. Maybe Tomasz can comment on this?

Am 19.05.2014 um 11:14 schrieb Thomas Heute <do-not-reply@jboss.com>:

 

 

JBoss Community

Runtime container choice. vert.x vs WF core vs Karaf vs ???

reply from Thomas Heute in rhq-metrics - View the full discussion

 

Agreed, and agreed that we could have several implementations.

 

 

 

I just want to keep it simple in the beginning, I think WF is the way to go for now (or UnderTow) and we can abstract later some parts. Obviously the minimum should be bound to WF/Undertow.

 

 

 

We only need 1 implementation to keep working on the API and have something to play with. We can grow from there.

 

Reply to this message by going to Community

Start a new discussion in rhq-metrics at Community

Following rhq-metrics in these streams: Email Watches

Following Runtime container choice. vert.x vs WF core vs Karaf vs ??? in these streams: Inbox, Email Watches

I spent time over the weekend on a embedded Cassandra solution[1]. There is still work to do, but I have made good progress so far. I should point out that the embedded approach is not intended for production use since as a number of Cassandra settings are tuned to really reduce its overall footprint. I have also started working on making it easier to work directly with the core Java API, e.g.,

// client code

RHQMetrics rhqMetrics = new RHQMetrics();

// add some data

rhqMetrics.addData(...);

// query for data

rhqMetrics.findData(...);

// shutdown

rhqMetrics.stop();

[1] jsanda/rhq-metrics at embedded-cassandra · GitHub

Heiko Braun wrote:

 

If we aim for WF, then it would probably make sense to go straight for WF 9. the whole extension model has been drastically simplified. Maybe Tomasz can comment on this?

 

 

There are two aspects of extension model that we are worked and are working on simplifing.

First is just java api (old DescriptionProvider vs ResourceDescription) which really simplifies development of extension.

I think last step of that evolution can be seen in IO & Undertow subsystems and by using PersistantResourceDefinition that helps you remove as much boilerplate code as possible, it even does parser code for you, you just need to describe what parser should look like, see mail subsystem parser for example

Current state gets near our vision for future, where there will be annotation driven model, but due to time constraints that probably wont make WF9.

Other aspect of extending WildFly(core) is build / distribution related, we are working hard on that as we need proper working solution to be able to do WildFly / WildFly core. as that will be the first case if our new build process works.

There are few working prototypes already done, but it is not ready to get into master quite yet.

Once this is done, having custom distribution based on Core/EE/Web/<some-other> will be extra easy as you will just specify what base distro you want and specify what you want to add on top of it.