Parent POM and Wildfly BOM
by Thomas Segismont
Hi everyone,
I've been working on the changes needed in Metrics for the parent POM
upgrade to version 16 (those introducing Wildfly 9).
There are three things I noticed which I believe are worth sharing.
Firstly beware that the Wildfly guys have changed their philosophy about
the BOM: now they force the "provided" scope in the BOM and exclude all
the dependencies they think you shouldn't care about as a EE7
application developer.
On one hand it frees you from adding the provided scope declaration in
your application POM. On the other hand, if you use one of the artifacts
in tests then dependency resolution could suddenly be broken.
Secondly our parent POM does not only declare the Wildfly POM in
dependency management section, in also imports it. Which means that all
our projects get forced versioning and scope, even if they are not
Wildfly based.
Thirdly, minor issue, the Wildfly Maven plugin does not configure a
default Wildfly version which means that we are all forced to declare in
components parent POMs. Like this in Metrics:
https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
Going forward, I propose that we no longer "import" the BOM in Hawkular
parent, and let components do it where needed. And that we declare the
Wildfly version to start with the Wildfly Maven plugin in the parent.
Regards,
Thomas
10 years, 9 months
Prototype of operations execution on the feed
by Heiko W.Rupp
Hey,
I have prototyped the execution of operations on the feed (WF-server for
now).
Note, that this is not any way of final implementation, but merely a
proof of
concept to get this started with the possibility to discuss some less
abstract situation/code.
Also for the "action on all selected items" - that is currently not
taking
the selected items only.
This works by having a new endpoint on the server
http://localhost:8080/hawkular/opsq
where a post to it submits one or more jobs onto the server.
A get to opsq/{feedid} then pulls one job for that feed.
The wf-agent now has a new runnable 'OpsGroupRunnable' that
once per minute polls that above endpoint and executes jobs that are
available.
I think that for a real implementation we should consider upgrading
the server-feed communication from many http/1.1 requests to
a websocket connection, that is then multiplexed on the server and
when something is added to the queue of jobs, it directly gets
pushed instead of the agent polling for it.
Also the result of the operation needs to be delivered back to the
server and ui; we need to add some unique operation id, to be able
to correlate request and result.
This also brings back the resource type discussion (see other email),
as e.g. a .war file does not support a :delete action. This needs e.g.
to
be broken out into a :undeploy and then remove-from-vf-content-repo
action. Or there are no :enable/:disable actions. They may need to be
translated into deploy/undeploy. Or greyed out in the UI.
The implementation spans multiple repositories - I do not intend
to send pull-requests, as this is only a prototype / proof of concept.
Hawkular-Monitor:
https://github.com/pilhuhn/hawkular-agent/tree/ops-get
UI-Services:
https://github.com/pilhuhn/hawkular-ui-services/tree/ops-get
Hawkular:
- QueueHandling
https://github.com/pilhuhn/hawkular/tree/ops-get/modules/ops-queue
- UI
https://github.com/pilhuhn/hawkular/tree/ops-get/ui/console/src/main/scripts
10 years, 9 months
Apps list search
by Gabriel Cardoso
Hello,
I was assigned to design the search/filter component for the applications list and would like to bring some questions. I already got some requirements from Liz/Thomas.
My proposal would be to present a behaviour similar to what JIRA does. They have “dropdown” selectors to allow filtering + a search box (initially).
For our context, the dropdowns would be to filter State (Up, Down etc.) and Type (EAP, Wildfly etc.). We probably don’t need the find input in the beginning, when we have not many options.
Thomas brought this comment:
> The input text should still be editable to do more filtering such as:
> "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com <http://corp.redhat.com/>' " (To show all servers on *.corp.redhat.com <http://corp.redhat.com/> that are down or unknown)
JIRA also covers that, when clicking on Advanced, the dropdowns are hidden and everything goes inside the search input:
I like this approach because we offer something user-friendly and at the same time provide something more powerful for advanced users.
I would like to hear your feedback.
@Inventory team, from what was presented, it is feasible to be implemented?
Thanks,
Gabriel
Gabriel Cardoso
UX designer @ Red Hat
10 years, 10 months
Inventory 0.1.0.Alpha3 released
by Lukas Krejci
Hi all,
In a surprising move, Inventory released its 0.1.0.Alpha3 version AFTER
0.1.0.Final. The release was cut from a branch branched off of a commit
preceding 0.1.0.Final such that 0.1.0.Alpha3 only contains the fix for
https://issues.jboss.org/browse/HWKINVENT-54 on top of what already has been
available in inventory 0.1.0.Alpha2.
This has been done so that Hawkular 1.0.0.Alpha2 can be released without any
further API breakage.
Thanks,
Lukas
10 years, 10 months
C* schema design
by John Sanda
I had been looking at the alerts schema briefly and wanted to share some thoughts on schema design in general. My understanding is that there can be many alerts for a single trigger. And based on my understanding and experience with RHQ, it is possible for there to be a large number of alerts. Here is the schema for the alerts table,
CREATE TABLE alerts (
tenantid text,
alertid text,
payload text,
PRIMARY KEY (tenantid, alertid)
)
Simple enough. Here is a short test driver[1] I wrote to insert 100 million alerts into a 3 node cluster. Note that only a single tenant is used. As the test ran, I periodically ran nodetool status to check the load on the cluster. You can see the output of that here[2]. You will that only of the nodes owns virtually all of load. 127.0.0.1 has over 2 GB of data while the other two have less than 500 KB each.
All of the alerts for a single tenant are stored in a single partition. In other words, all alerts are stored in one physical row on disk. This does not scale. Regardless of the number of nodes, only one node owns all of the data for a given tenant. This will also probably increasingly negative impact on read performance.
The first change I might consider is to partition by trigger, but that alone is probably not sufficient. What if a single trigger generates thousands of alerts per day? That is still going to lead to hot spots (i.e., partition becoming too large). I would also consider partitioning by some time slice. Something like this,
CREATE TABLE alerts (
tenantid text,
triggerid text,
date timestamp,
alertid text,
payload text,
PRIMARY KEY ((tenantid, triggerid, date), alertid)
)
Now data is partitioned by tenant, trigger, and date. The date column might be rounded down to week, day, hour, etc. It really depends on the frequency of writes as well as the read patterns. Now the data will be spread across nodes in a more scalable way. And when you have to fetch data across multiple time slices, you can execute the queries in parallel.
[1] https://gist.github.com/jsanda/ce07905fa9f16f13c661 <https://gist.github.com/jsanda/ce07905fa9f16f13c661>
[2] https://gist.github.com/jsanda/6d2ee6cd5bcab07331d2 <https://gist.github.com/jsanda/6d2ee6cd5bcab07331d2>
10 years, 10 months
Inventory 0.1.0.Final released
by Lukas Krejci
Hi all,
Inventory 0.1.0.Final has just been released.
A couple of new features and enhancements have been made since 0.0.9, which
you can read about here:
https://issues.jboss.org/browse/HWKINVENT/fixforversion/12327452
Some of the notable changes:
* REST API solidified and made more regular - associating metric types to
resource types is done similarly to how metrics are associated to resources,
etc.
* Tenant ID no longer part of the URL - it is implied from the login
credentials and current persona.
* Basic filtering support for resources (above of what was available in an ad-
hoc manner before)
* REST API now can work with generic, free-form, relationships
* Resource types no longer have mandatory version - this is going to come back
at later releases in a very different and most probably transparent way.
* Internally, much of the implementation has been factored out into a backend-
agnostic place, leaving us in a much better place when inventory will be
ported to Tinkerpop3 and Titan 1.0.
Unfortunately, the big features originally slated for this release - running
on Titan 0.5.x and support for resource hierarchy, slipped into the next
release, where they should be ready relatively shortly.
Big thanks go out to Peter Palaga who fixed many of the REST API problems and
implemented resource filtering.
Cheers,
Lukas
10 years, 10 months
[Apache Cassandra] Fwd: Partner Newsletter – Global Payment Technology Company Chooses Azul and Feedzai
by Lucas Ponce
Interesting related a big cassandra installation.
----- Forwarded Message -----
> From: "Azul Alliance Partner Program" <partners(a)azulsystems.com>
> To: lponce(a)redhat.com
> Sent: Tuesday, June 30, 2015 5:02:59 PM
> Subject: Partner Newsletter – Global Payment Technology Company Chooses Azul and Feedzai
>
> Subscribe:
> http://info.azulsystems.com/SubscriptionCenter_Subscribe_partner_newslett...
>
>
> June, 2015 Alliance Partner Newsletter
>
>
> Feedzai and Azul Deploy Real-Time Fraud Detection Solution at Global Leader
> in Payment Technology
>
> Azul and Feedzai collaborated to implement a real-time Apache
> Cassandra™-based fraud detection use case for a major financial services
> account. By deploying on Zing, which is fully certified with Feedzai, the
> company is able to ensure the system can consistently meet response time
> requirements in the 10s of milliseconds.
>
> Read more:
> http://www.azulsystems.com/press-2015/feedzai-and-azul-systems-deploy-rea...
>
>
> Top News and Resources
>
> • M2M Now: Why has Azul Systems launched Zulu Embedded?
> Read More:
> http://www.m2mnow.biz/2015/06/15/34001-why-has-azul-systems-launched-zulu...
>
> • Application Development Trends: Oracle Considers G1 Garbage Collector for
> Java 9. Read More: https://adtmag.com/articles/2015/06/22/oracle-java-9.aspx
>
> • Application Development Trends: Oracle Pushes Java EE 8 Release Date.
> Read More: https://adtmag.com/articles/2015/06/08/java-ee-8-release-date.aspx
>
> • InfoQ: Oracle Proposes G1 as the Default Garbage Collector for Java 9.
> Read More: http://www.infoq.com/news/2015/06/Oracle-Proposes-G1-Default-GC
>
> • BetterJava Blog: So, G1 may become the default collector for Java 9?
> Read More:
> https://betterjava.wordpress.com/2015/06/18/so-g1-may-become-the-default-...
>
> • InfoWorld: Java at 20: The JVM, Java's other big legacy.
> Read More:
> http://www.infoworld.com/article/2923035/java/java-at-20-jvm-javas-other-...
>
>
> Upcoming Events
>
> OSCON
> July 20 - 23
> Meet the Azul Systems team in booth #319 to discover open source Java
> options.
> More detail: http://www.azulsystems.com/content/oscon-2015-0
>
> Embedded Systems Conference Silicon Valley
> July 20 - 22
> Meet the Azul Systems team in booth #40 for scalable, fully customizable open
> source Java for embedded systems and the IoT.
> More detail:
> http://www.azulsystems.com/content/embedded-systems-conference-santa-clar...
>
> ÜberConf Denver
> July 21 - 24
> Azul VM Engineer Douglas Hawkins will be presenting four sessions on Java
> topics.
> More detail: http://www.azulsystems.com/content/%C3%BCberconf-denver-2015
>
>
> Azul Systems is the award-winning provider of Java for the enterprise. The
> company has over 10 years' experience and deep domain knowledge in Java
> runtimes, low-latency applications, elastic memory, Pauseless Java Garbage
> Collection and runtime resource monitoring. Azul is also a member of the
> Executive Committee of the Java Community Process (JCP) and a Silver Member
> of the Cloud Foundry Foundation. www.azulsystems.com
>
>
> ©Copyright 2015, Azul Systems, Inc. | 1173 Borregas Ave | Sunnyvale CA 94089
> | Phone : 650-230-6500
>
> To ensure delivery of messages from Azul Systems please add
> azul(a)azulsystems.com to your address book. If you no longer wish to receive
> these emails, go to the following link to unsubscribe:
> http://www.azulsystems.com/teal-azul/about_us/email_subscription?mkt_unsu...
>
10 years, 10 months
Hawkular Metrics Containers Changes
by Matt Wringe
Just a heads up that I will need to delete the existing docker hub
'hawkular/hawkular-metrics' and 'hawkular/hawkular-cassandra'
repositories. This is so we can convert the 'automated build' repository
to a normal one (we cannot convert one to another, it has to be deleted
first).
This will finally allow us to build the docker images ourselves and push
them out after the tests have passed.
I will probably make this change tomorrow if there are no objections.
Thanks,
Matt Wringe
10 years, 10 months
