DZone article about NoSQL databases
by Heiko W.Rupp
Hi,
just found this DZone article about "What NoSQL store should I use": http://architects.dzone.com/articles/what-nosql-store-should-i-use
I can imagine that this may be an interesting route for us for storing/processing Events and Calltime data.
Also there are graph-DBs that could fit well Greg's idea of tracking calls from UI to EJB methods to SQL statements.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 8 months
Things I dont know how to do with plugins
by Bryan Kearney
Working through a plugin, there were a couple of things I did not know
how to do. Any pointers on best practices would be appreciated.
1) I would like to exposed operations based on the state (availability)
of the resource.
2) I would like to kick off discovery based on an operation being executed.
3) I would like to update availability based on an operation.
I assume some/all of this is supported.
-- bk
13 years, 9 months
leaking classloaders
by John Mazzitelli
If anyone is interested in helping me analyze heap dumps to find where
we are leaking classloaders, let me know. I think I need another pair of
eyes. I can give folks my hprofs if you know how to analyze them and/or
we can review them together. This is the BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=615377
For sure we leaked EMS classloaders due to a SUN JVM bug - that much I
am certain. And I fixed it locally on my box. If you care, this is the
SUN bug - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6727821 -
I'm still baffled why they are caching this context classloader in a
static data member, but they are and it causes problems and we need code
to workaround it. In addition, our JBossAS 5 plugin and EMS is storing a
JBoss-specific Configuration object inside this javax Configuration
object (see Configuration.setConfiguration()) and thus leaks that object
and its classloader.
Unfortunately, it doesn't solve the entire problem. Running in
JProfiler, I still see perm gen leaking. Doing a "plugins update"
numerous times will eventually result in an OOM-PermGen. This only
happens if you are managing JBossAS instances.
So what I did was I captured 5 hprof heap dumps:
1) the first at agent startup with --nostart --nonative --console=java
option. This is the agent core started, but the PC is not started and
there is no native code enabled. Memory footprint is very small, and
only our input thread is running.
2) the second hprof is taken after I did a "start" - the PC is started
and it has JBossAS instance in inventory.
3) the third is taken after a "shutdown" - all threads are dead but the
input thread. At this point, this hprof should be able to see leaked
classloaders.
4) I started the PC again via "start" and took a fourth hprof
5) Finally, I "shutdown" the agent internals a second time and took
another hprof.
At this point, if we compare hprof #1 vs. #5, they should be very
similar but due to the leakage, we should be able to compare the two and
find the leakages. This is the part I'm having problems with. This is
how I found the javax Configuration leak, but I haven't found anything
else.
13 years, 9 months
How to internationalise the rhq-plugin descriptor file
by Michael Musgrove
There are plenty of strings in the rhq-plugin.xml file that end up
getting displayed in the console. Is there any mechanism for
internationalising this text?
If not has the topic already discussed or can we kick off a thread to
get this resolved.
Thanks,
Mike
--
Michael Musgrove
13 years, 9 months
RfC: Resource tree database setup
by Heiko W.Rupp
Hi,
With in Resource.java we define quite some queries like
Resource.QUERY_FIND_DESCENDENTS
that go
+ "SELECT r.id " //
+ " FROM Resource r " //
+ " WHERE r.id = :resourceId " //
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.id = :resourceId) "
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.parentResource.id = :resourceId) "
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.parentResource.parentResource.id = :resourceId) "
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.parentResource.parentResource.parentResource.id = :resourceId) "
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.parentResource.parentResource.parentResource.parentResource.id = :resourceId) "
+ " OR r.id IN (SELECT rr.id FROM Resource rr WHERE rr.parentResource.parentResource.parentResource.parentResource.parentResource.parentResource.id = :resourceId) "
Oracle EM reports very high cpu usage when processing them.
I wonder if we should add a 'helper table' (or materialized view), which gets updated on resource creation/deletion
a little like this:
RHQ_RESOURCE_PARENT_CHILD (= X in the following examples)
(
int resourceId;
int childId;
int resourceTypeId;
int childTypeId;
int resourceCategoryId;
)
with a pk of (resourceId, childId)
Entries would be for each resource id we have in inventory its id, the ids of all of its children, type of resource, category of resource.
Some example queries:
- To find the parent platform of a resource
select resourceId from X where childId = :child and resourceCategory = platform;
- To find all resources below a given root (e.g. for marking as uninventoried)
select childId from X where resourceId = :root;
- To find all children of a certain type (= autogroup)
select childIf from X where resourceId = :root and childTypeId = :childType
- mark all children of a root as deleted (2 steps now, 2nd one to get rid of resources to delete from X )
update RHQ_RESOURCE set INVENTORY_STATUS= :status ,...
where id in (select childId FROM x where resourceId = :root)
delete FROM X where resourceId = :root
I am sure that there are a ton more of information that could be included here
like the 'owner' of a resource or its name. In any cases some good indices
would be needed.
Also to replace existing queries, in some cases would perhaps need two
roundtrips to the database, so in this case one would need to investigate
the benefits here.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 9 months
Remote_Debugging
by Alexander Kiefer
Hello,
I needed to add a method to the ResourceMetadataMangerLocal interface of my
Nagios branch and implemented it in the according bean because I´m working
on the usage of dynamic metadata. The goal is to generate new ResourceTypes
at runtime.
*************************************************************************************************************
/** Method to add a runtime-created resourceType to an existing plugin */
public void addNewResourceType(String newResourceTypeName) {
Plugin plugin = null;
try {
plugin =
LookupUtil.getResourceMetadataManager().getPlugin("NagiosMonitor");
} catch (NoResultException nre) {
//NoResultException is thrown if no plugin with spcific name
exists
log.error(nre);
}
log.info("Name of returned plugin: " + plugin.getName());
//Method to get the parent resource Type
//Got name and plugin from the rhq_resource_type table in the rhq
database
ResourceType parentResourceType =
LookupUtil.getResourceTypeManager().getResourceTypeByNameAndPlugin(
"NagiosMonitor", "NagiosMonitor");
log.info("Name of parent ResourceType: " +
parentResourceType.getName());
ResourceType newResourceType = new ResourceType(newResourceTypeName,
plugin.getName(),
ResourceCategory.SERVICE, parentResourceType);
log.info("Name of new ResourceType: " + newResourceType.getName());
updateType(newResourceType);
}
**************************************************************************************************************
As far as I can see in the log files the method seems to work correct, but
no persistence of the new ResourceType is done in the DB allthough the log
file says that the methods are called correctly (those methods that are
called within the updateType() - method).
So I need to debug the running code in the RHQ Server. I only did this with
standalone JBoss AS and not with the embedded JBoss in the RHQ server. On
standalone JBoss I would add the following line to the run.sh of the Jboss
AS. If i do this in the embedded JBoss, the server can´t be started any
more.
JAVA_OPTS="$JAVA_OPTS -Xdebug
-Xrunjdwp:server=y,transport=dt_socket,address=8787,suspend=n"
I dont want to set RHQ_SERVER_DEBUG to get additionally debug messages or
mvn -Dtest.debug to debug my unit tests. What i want is to debug my running
beans step by step from Eclipse to find out what is going wrong .How can i
handle this?
Thank you very much,
Alex
13 years, 9 months