Meeting with Dan, Andrew and Lincoln
by Heiko W.Rupp
Andrew, Dan and Lincoln have been here in Stuttgart to give three great talks at the user group
(could you please send the links to the talks?).
Luckily I had also time to talk to them and we had a few areas where we could do stuff together
- Arquillian[1] has currently an integration with Selenium to drive UI tests. I told Dan about our
experiences with Selenium and GWT and that Sahi[2] is now working well for us[3]. Dan thought
it may be a good idea to investigate the integration of Sahi with Arquillian, which we could use
later.
- There is an api called ShrinkWrap[4], that basically allows to construct an archive via java methods
and then to stream that created "archive" into a container for testing. ShrinkWrap is a part of Arquillian,
but (afaiu) also available standalone. We could enhance our plugin container to accept ShringWrap
"archives" so that for testing we do not need to create .zip files and put them somewhere in the filesystem
anymore, which may make plugin testing a lot easier.
- JBoss Forge[5] is a tool (standalone or within JBossTools[6] (!) ; integration into IntelliJ is expected to come),
that allows to create a skeleton project from scratch or to enhance an existing project. We had the idea to
integrate our plugin generator into it, so that users can in Forge say "with monitoring" and the application
gets monitoring hooks created. Also this would allow to generate a skeleton plugin (much like the
generator does today). A functionality like this could make it easier for application writer to enhance
their app for more app/biz-level monitoring and thus better integration with RHQ.
Heiko
[1] http://www.jboss.org/arquillian
[2] http://sahi.co.in/w/
[3] http://www.youtube.com/watch?v=pbOIBl8E9ls
[4] http://www.jboss.org/shrinkwrap
[5] https://docs.jboss.org/author/display/FORGE/Home
[6] http://www.jboss.org/tools
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 5 months
Hadoop plugin questions; JMX
by Elias Ross
I'm seriously looking at the Hadoop plugin but have a couple of
comments and questions.
1. Not sure why the traditional JMX plugin was not used. Is the JMX
plugin not sufficient? I do notice the metrics across multiple MBeans
get grouped together nicely but I don't see much value in doing this.
Can I simply drop this code and start fresh? Or is this an approach
that should maybe be implemented in the JMX plugin itself. For
instance:
<service name="Aggregate Service"
discovery="MBeanResourceDiscoveryComponent"
description="Two MBeans in one service">
<plugin-configuration>
<c:simple-property name="objectName" readOnly="true"
default="captured"/> <!-- captured from the property name -->
</plugin-configuration>
<metric displayName="Foo"
property="hadoop:service=NameNode,name=FSNamesystemState|BlocksTotal"
description="Number of active threads in the system"/>
2. It's incomplete, obviously, and many of the metrics don't show up
with the Cloudera version I need, which is perhaps newer. I do intend
to fix this. Is there any need to keep what's there? (I'd say no.)
3. There are many values that are totals and available, so I'd like to
make ratios out of them. For example, if the total space is 1TB and
the available is 10GB, I'd like to set up an alert on < 10%
availability. What's the recommendation on how to alert on something
like this? (Maybe more of a user question, I guess.)
4. Are there tools for generating rhq-plugin.xml from an MBean server
connection? Basically it would spit out a <service> for each
ObjectName and properties and operations for each MBean attribute and
operation. I would think this could be fairly useful. The generated
plugin would obviously need to be edited by hand but this would save a
lot of work for many users.
12 years, 5 months
heads up - settings.xml change may be needed
by Ian Springer
Note, due to the fix I just checked in for
https://bugzilla.redhat.com/show_bug.cgi?id=752239, you may need to make
a change to your settings.xml. If your settings.xml currently contains:
<gwt.locale>default</gwt.locale>
then you will now need to also add:
<gwt.fallback.locale>default</gwt.fallback.locale>
Here's all the GWT related props I currently have for the dev profile in
my settings.xml:
<!-- Only gwt-compile JavaScript for FF2 and later. -->
<gwt.userAgent>gecko1_8</gwt.userAgent>
<!-- Enable faster, but less-optimized, gwt compilations. -->
<gwt.draftCompile>true</gwt.draftCompile>
<!-- Only compile the "default" locale. -->
<gwt.locale>default</gwt.locale>
<!-- If user specifies an unsupported locale, fallback to the "default"
locale. -->
<gwt.fallback.locale>default</gwt.fallback.locale>
12 years, 6 months
4.3.0: Issues with plugin unit testing; oracle plugin integration
by Elias Ross
I'm working on improving the Oracle plugin and wrote a unit test to
test against my database. The test runs fine within Eclipse but within
Maven,
I run into issues.
At the moment, I am seeing this:
Caused by: java.lang.IllegalArgumentException: interface
org.rhq.core.pluginapi.inventory.ResourceComponent is not visible from
class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at org.rhq.core.pc.inventory.ResourceContainer.createResourceComponentProxy(ResourceContainer.java:381)
at org.rhq.core.pc.inventory.InventoryManager.activateResource(InventoryManager.java:1576)
at org.rhq.core.pc.inventory.InventoryManager.mergeResourceFromDiscovery(InventoryManager.java:1354)
at org.rhq.core.pc.inventory.InventoryManager.executePlatformScan(InventoryManager.java:505)
at org.rhq.core.pc.inventory.InventoryManager.initialize(InventoryManager.java:226)
at org.rhq.core.pc.PluginContainer.startContainerService(PluginContainer.java:431)
at org.rhq.core.pc.PluginContainer.initialize(PluginContainer.java:282)
at org.rhq.plugins.oracle.ComponentTest.<init>(ComponentTest.java:96)
at org.rhq.plugins.oracle.OracleServerComponentTest.<init>(OracleServerComponentTest.java:19)
... 34 more
Here is the relevant code. I imagine this is due to the
'pluginClassLoader' not having a reference to the API class.
public class ResourceContainer implements Serializable {
ClassLoader pluginClassLoader =
this.resourceContainer.getResourceClassLoader();
if (pluginClassLoader == null) {
throw new IllegalStateException("No plugin class
loader was specified for " + this + ".");
}
Thread.currentThread().setContextClassLoader(pluginClassLoader);
I'm also wondering how to integrate the unit tests for this plugin, as
it depends on an actual Oracle database as well as configuration
details.
Currently I invoke using:
mvn -Poracle-test -Doracle.url=jdbc:oracle:thin:@hostname:1521/sid
-Doracle.username=user -Doracle.password=pw
If you don't plan on having this sort of testing automated, then it
might make sense to require users to manually invoke, and I will
disable the tests by default. I thought of centralizing this sort of
config but: 1) It's a lot of work 2) And doesn't really have much
value outside of this one plugin.
12 years, 6 months
*heads up* mvn clean install of jmx plugin module needed
by Ian Springer
[master 9c437b0] upgrades EMS from 1.2.16 to 1.3 in the root pom.
Similarly, commit dc4a80e upgrades EMS to 1.3 on the release_jon3.x branch.
Once you've pulled either of these commits, make sure to:
cd rhq
mvn -N install
cd modules/plugins/jmx
mvn clean install
Otherwise, you'll end up with two versions of the EMS jar inside the jmx
plugin jar, which will have unpredictable, and most likely bad, results.
12 years, 6 months
RTI v3.2 - RHQ Edition announcement
by Steven North
OC Systems is pleased to announce the beta release of RTI v3.2 - RHQ
Edition. This new version integrates the new application performance
monitoring capabilities of RTI into the RHQ management framework and
leverages the alerting capabilities of RHQ to collect real-time
diagnostic data. Support for JBoss Operations Network will be available
shortly with the upcoming release of JBoss Operations Network 3.0.
RTI automatically discovers application business transactions in JBoss
and Tomcat applications and collects transaction based response time and
throughput metrics which are managed by RHQ. RTI also performs
lightweight transaction profiling, which provides a method-level
breakdown of where time is spent in each business transaction. RTI can
also perform distributed transaction tracing to follow an application
transaction though the distributed application layers starting at the
browser, collecting context information along the way.
RTI transaction profiling and transaction tracing can be enabled
manually or on-demand using RHQ alert notifications. RTI alerts can
initiate profiling or diagnostic tracing globally or for individual
transactions over fixed intervals. The resulting profile and trace data
snapshots collected by RTI alerts are recorded on the RHQ server for
later analysis. RTI alerts can fire based on any RHQ resource metric
and can initiate profiles and traces in multiple applications/platforms
simultaneously.
The RTI profile and trace snapshots can be analyzed in the RTI Console.
The RTI Console can list and download the RTI alert snapshots recorded
on the RHQ server and can also download RHQ metrics for display and
analysis with the RTI data.
A more comprehensive listing and description of features can be found in
our feature-tour - http://www.rtiperformance.com/feature-tour.
For more information on the RTI v3.2 - RHQ Edition and information about
the beta program, and RHQ supported platforms, please visit
http://www.rtiperformance.com/landing-rti-v32-rhq-beta.
P.S. Thanks to all the developers on the rhq-devel list who answered
questions and provided guidance during our effort.
12 years, 6 months
Fwd: [Bug 714812] once a Resource is deleted via RHQ, if the underlying managed resource is later recreated and rediscovered by the Agent, it causes an invalid inventory report error in DiscoveryServerServiceImpl & prevents discovery of any new Resources from that Agent
by Ian Springer
Lukas-
I was just looking at this one and thinking a bit about the best way to
fix it.
As I recall, when we discussed this briefly at the F2F, it was agreed
that the main reason we were leaving DELETED Resources in inventory was
so that if the Resource got rediscovered (after the underlying managed
resource was recreated), it could be re-attached to its old metric data
and other histories.
First on the Server side, there is the below code in
DiscoveryBossBean.updatePreviouslyInventoriedResource():
// If the resource was marked as deleted, reactivate it again.
if (existingResource.getInventoryStatus() ==
InventoryStatus.DELETED) {
existingResource.setInventoryStatus(InventoryStatus.COMMITTED);
existingResource.setPluginConfiguration(updatedResource.getPluginConfiguration());
}
This has the right idea, but I think it should be changing the status to
NEW, not COMMITTED, if it's a platform or a top-level server, since in
that case the user should have to import it in order for it to become
COMMITTED. The logic would actually be very similar to what we do for
newly discovered Resources in initAutoDiscoveredResource(). There is
also some other logic in that method we might also want to do like
setting the itime to the current time (though I don't know if it makes
more sense to leave the itime set to the original pre-DELETED inventory
time).
In addition to fixing up the logic in DiscoveryBossBean, I'm guessing
there will also be some changes needed to the sync code in
InventoryManager on the agent side. For one thing, if a previously
DELETED Resource gets rediscovered, we should make sure it ends up
having the same uuid and id as the existing Resource on the Server side,
so it doesn't end up getting blown away by purgeObsoleteResources(). I
haven't done that much thought on the agent side though - it will
probably require a bit of experimentation and debugging to figure out
what needs to be changed. In any case, I'd fix up DiscoveryBossBeanfirst.
--Ian
-------- Original Message --------
Subject: [Bug 714812] once a Resource is deleted via RHQ, if the
underlying managed resource is later recreated and rediscovered by the
Agent, it causes an invalid inventory report error in
DiscoveryServerServiceImpl & prevents discovery of any new Resources
from that Agent
Date: Wed, 2 Nov 2011 12:05:07 -0400
From: bugzilla(a)redhat.com
To: ian.springer(a)redhat.com
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=714812
Lukas Krejci<lkrejci(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |lkrejci(a)redhat.com
AssignedTo|rhq-maint(a)redhat.com |lkrejci(a)redhat.com
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.
12 years, 6 months