Need advice about agent plugin design
by Steven North
I am trying to design an RHQ/JON agent plugin to manage a software
resource with the following characteristics:
- there is the software itself (the installation);
- there are a variable number of "bundles" of configuration information
about 250KB in size each which need to be read from and written to the
agent; and
- there are "log" files which can 10-50MB in size each which need to be
read from the agent.
I think I am pretty clear on how to handle the software itself--just
like any number of other agents.
I am not sure how to handle the configuration bundles and the large log
files.
We might want to have the RHQ/JON server manage different versions of
these configuration files and distribute them to multiple remote agents.
Is there some existing domain object that would handle the read/write
aspect of the configuration bundles (zip files)? Could the "package"
concept be used for these? Would we need to create a new domain object
on the server side for these bundles? If so, is there an example of
this kind of thing?
For the log files, I see some mention of the SupportFacet. Would this
be appropriate for retrieving large log files? Is there an example of this?
We expect to access the configuration bundles and the log files using
remote client operations because we have a separate GUI tool to
build/edit the configuration bundles and to correlate and analyze the
log files. Is there an example of using a remote client to pull files
from and push files to remote agents?
Thanks in advance for any advice you can give or examples you can point to.
Steve
10 years, 1 month
Release 4.1.0 beta available
by Heiko W.Rupp
The RHQ team is happy to announce the immediate availability of a BETA release of the upcoming
4.1.0 release.
This beta contains a wealth of new features and bug fixes and serves as a preview for 4.1 and
to gather feedback. Please note that some of the new features are still work in progress (and
will be for some time) - this means that *you* can still influence the new features by your
feedback.
You can find the release notes at http://rhq-project.org/display/RHQ/Release+Notes+4.1.0+beta
which also contain a link to the downloads.
We want to especially thank Elias Ross, Fusayuki Minamoto, Jijun Liu, Zhongqianglee
and Rafael Torres Coelho Soares for their contributions
Heiko on behalf of the whole team.
--
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
key and default name for AS7 Server Resources
by Ian Springer
Heiko,
I noticed the jboss home dir (e.g. /opt/jboss-as-7.0.1.Final) is used as
the key and default name for AS7 Server Resources. Is this safe? In
earlier versions of AS, you could run multiple server instances out of
the same home dir, so we used the server config dir
(/opt/jboss-6.0.0.Final/server/config/default) as the key. And for the
default name we used the hostname + port.
-Ian
12 years, 7 months
augueas dep on plugin-container
by John Mazzitelli
I'm curious why plugin-container module has a dependency on augeas. the
PC should not have a dependency on augeas - the PC is platform agnostic
and no code should be relying on a very platform specific library like
augeas.
If this is here to support packaging of the distro (which I suspect it
is) we should come up with another way. I know the augeas plugin itself
has the dependency (as well it should) so I would think that should be
good enough.
Anyway, I think we should discuss this, just so its clear why it is
there and if possible, change it.
12 years, 7 months
Better HTTP monitoring plugin?
by Elias Ross
I put together an HTTP monitoring plugin. Mostly because I didn't
realize "NetServices" had support for HTTP already. (More on this in a
bit.)
Anyway, my purpose was to create something that could pull
measurements/metrics from a web page. I thought I could with the
script plugin, but seemed like a bit of hack. The plugin is not
necessarily something for monitoring a page, but it does do that too.
For example, if you had a page like:
http://localhost:8080/myapp/stats.jsp:
Number of purchases: 52
Time to process: 21.21
Errors: 4
You could graph that stuff in RHQ. If you extend the plugin, your
config would appear like:
<plugin-configuration>
<c:simple-property name="url" required="true"
default="http://localhost:8080/myapp/stats.jsp" ...
...
<metric property="purchases: (\d+)" dataType="measurement"
displayName="purchases" ...
Like the script plugin it extracts metrics from a regex. It's a little
more straightforward as you don't pass arguments to the page, you just
expect the page to contain all the metrics you need.
Also as a plugin, it can also "auto discover", similar to users who
extend the JMX plugin with a specific MBean, web pages that are served
locally. So you don't need to manually add it. It will do an "HTTP
GET" and add itself.
There are some quirks with it and the display data may need to be
tweaked. I don't know how to name it. I call it 'HTTPServer' but it's
really not a *server*, more like a HTTP page monitor.
Another nice thing is my Plugin has a comprehensive unit test suite.
So all the features are tested, at least as well as I can outside RHQ.
I don't really know what to do with it. I may just move the features
to NetService's HTTP plugin, including tests. But only if there's some
more interest. Or it may be wise to keep the existing plugin as-is and
just create one that's 'newer.'
12 years, 7 months
On Proper Handling of Interrupts in Java Code
by Robert Buck
Hi Folks,
I was looking at a support case when I noticed this sort of code...
try {
this.lock.lockInterruptibly();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
The lockInterruptibly() API used above throws an InterruptedException IF
the thread is interrupted while acquiring the lock OR IF the thread is
currently interrupted; the latter is perhaps the most common case, and
the former typically only occurring during shut-down. The catch block
fails to restore the current threads interrupt status (it eats the
interrupt). Failing to properly restore a threads interrupt status can
lead to unanticipated application behaviour, and occasional (extremely
difficult to diagnose) instability.
Could we please follow standard techniques for handling interrupts?
Five years ago, back in 2006, IBM wrote a decent article on interrupts,
it's a pretty good read; it is especially useful before writing APIs so
that from day one they are interrupt safe. I found the document very
well written and the guidelines helpful to me in creating other products
since 2007. Here is the link:
http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html
A quick scan across the code base reveals:
* (0) occurances of Thread.currentThread().interrupt();
* (94) occurances of catch-InterruptedException
Rather than eating interrupts, it is better to set the interrupt status,
as the following rewritten code does:
try {
this.lock.lockInterruptibly();
} catch (InterruptedException e) {
// lets callers service interrupts!
Thread.currentThread().interrupt();
throw new RuntimeException(e);
}
Cheers,
-Bob
12 years, 7 months
JMX and Class Names
by Stefan Negrea
Hello Everybody,
I think an e-mail is much better to capture and explain the JMX problem I am running into.
mod_cluster is configured through a bean configuration file.
Here is the configuration for the top service:
1 <bean class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" name="ModClusterListener">
2 <constructor>
3 <parameter class="org.jboss.modcluster.ContainerEventHandler">
4 <inject bean="HAModClusterService"/>
5 </parameter>
6 <parameter class="javax.management.MBeanServer">
7 <inject bean="JMXKernel" property="mbeanServer"/>
8 </parameter>
9 </constructor>
10</bean>
The default configuration is set with HA version of the mod_cluster service. To change it to the regular version, one just need to remove the HA moniker for the injected bean on line 4.
4 <inject bean="ModClusterService"/>
Here is a snippet of configuration for the regular bean:
<bean class="org.jboss.modcluster.ModClusterService" mode="On Demand" name="ModClusterService">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.web:service=ModCluster",exposedInterface=org.jboss.modcluster.ModClusterServiceMBean.class)</annotation>
And here is snippet of configuration for the HA bean:
<bean class="org.jboss.modcluster.ha.HAModClusterService" mode="On Demand" name="HAModClusterService">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.web:service=ModCluster",exposedInterface=org.jboss.modcluster.ha.HAModClusterServiceMBean.class)</annotation>
Both of them use the same JMX name, jboss.web:service=ModCluster, so the only way to differentiate between them the two is the class name.
The current JMX RHQ plugin does discovery only based on the service name. So I had to write a custom discovery method that first runs the regular JMX discovery and then checks the class name of each bean discovered. If the className attribute of the service does not match emsBean.getClassTypeName(), then the bean is discarded from the collection of services discovered by original JMX procedure (link to the class name based discovery component: http://bit.ly/mYyL9x). Here is snippet of code:
1 String className = context.getDefaultPluginConfiguration().getSimple(CLASS_NAME).getStringValue();
2 return className.equals(emsBean.getClassTypeName());
I wrote a similar implementation for the availability of these services; check first if the bean is available and then check if the class of the bean is the one expected.
And here is where the problem starts. At any point the user can change from using the regular service to using HA service (and vice-versa). As soon as the change is saved to file, the microcontainer reloads the beans and the new resources are available. The current JMX RHQ implementation does not return the class name changes after the microcontainer reloads. So, if the HA service was originally loaded but swapped with regular service, the microcontainer will report correctly the new class name. However, the JMX RHQ code will continue to report the old class name until the RHQ agent is restarted or the JBoss server is un-inventoried and inventoried (basically disconnect completely from the JMX provider and reconnect).
I had a couple of attempts to fix, the most notable ones are:
* Refresh the bean attributes before getting the class name:
1. emsBean.refreshAttributes();
2. emsBean.getClassTypeName();
* Refresh the connection provider before getting the class name:
1.emsConnection.refresh()
2.emsBean.getClassTypeName();
But none of these approaches worked. The class name was not updated until the JBoss server was re-inventoried or the agent restarted. I also checked the source code for mc4j but I cannot see anything that could help.
Does anybody know how I can do a full reload of the JMX connection to pick such changes? If there is a way, how costly it is in terms of performance (this would be used not only in the discovery but also to check the availability the services)? Any other ideas of what I can do?
Thank you,
Stefan Negrea
Software Engineer
12 years, 7 months
mod_cluster & Config File Updates
by Stefan Negrea
Hello Everybody,
mod_cluster does not have support for persisting configuration changes in JBoss 4.2 and 5.1. The only solution is to explicitly update config files. I searched the code base for previous work on updating files but I did not find something that fits my use case. So, I will need a little bit of help (code review and questions).
JBoss EAP 5.1.x - Code Review
There is almost nothing exposed through JMX; everything is in the mod_cluster config file (${JBoss512}/jboss-as/server/all/deploy/mod_cluster.sar/META-INF/mod_cluster-jboss-beans.xml). I wrote a simple utility to update this file.
Because the file is only used by the mod_cluster module, I assumed that there is no other RHQ plugin that would attempt to update it simultaneously. Is this a good assumption?
I would appreciate a code review for the following two classes:
ModClusterBeanFile:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/m...
AbstractConfigurationFile:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/m...
JBoss 4.2.x - Design Question
The mod_cluster interface is completely different and allows settings to be updated over JMX. The problem is that after a server restart everything is reverted to default. The only way to persist configuration changes is to update the Listener tag in server.xml (${JBoss42}/server/all/deploy/jboss-web.deployer/server.xml). The mod_cluster bean configuration file is not available in this case (the module is deployed as a packaged jar and the interface is completely different).
I searched the code base but I could not find any other JBoss plugin that updates/reads this file. I want to follow the same pattern as JBoss 5.1.x but I have a couple of questions. Is the assumption that this file is not updated by any other plugin a good assumption? And, is there code that I could reuse for this purpose (just want to make sure I did not miss anything with my search)?
If I am to write the code from scratch, it would be even simpler than ModClusterBeanFile (there is only one tag with various attributes to update) and would be based on the AbstractConfigurationFile.
Here is the package I created to updating config files:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=tree;f=modules/plugins/m...
I attached sample config files for each server:
mod_cluster-jboss-beans.xml - JBoss 5.1
server.xml - JBoss 4.2
Thank you,
Stefan Negrea
Software Engineer
12 years, 7 months