Hibernate Performance Monitoring

Joseph Marques has a very good blog (good in both substance and technical details) on how you can analyze the performance of your Hibernate application through the use of a simple set of utility classes. He even goes into how you can do this inside your EJB3 app. We do this when analyzing performance in RHQ (in addition to using RHQ itself to do some analysis). Joe's code examples show that it's a solution that is easily transferable to any Java application that uses Hibernate as its ORM layer.

Monitoring JBossAS Clusters with RHQ

CirrAS is an effort to automatically deploy clustered JBoss AS servers in the Cloud. With so much focus on cloud computing these days, keep an eye on this CirrAS project.

The CirrAS guys are currently using RHQ to monitor every JBossAS instance in the cluster and recently utilized the RHQ CLI to perform some automation steps to get some RHQ things setup. For a description of what they did, see http://cloudpress.org/2010/01/29/rhq-cli-configuring-and-importing-resources/. Eventually, the CirrAS team wants to use RHQ to manage every node in the JBossAS cluster (deploy app, restart, etc).

Idiot Lesson On The Types Of SQL JOINs

I'm going to take a departure from my usual topics and talk briefly about a very basic concept - SQL JOINs. I'm doing this mainly for my benefit - I wanted to write this little nugget down so I don't forget it, and what better place to do so than my blog? :)

What's the difference between INNER, LEFT and RIGHT JOINs?

It seems every so often, I forget the answer to that question - I usually get confused ("what happens if there is a null - do I get a row in my results or not?"). Now, I'm sure it is easy for most people to remember how these JOINs work, but I always seem to forget. However, recently I got a good idiot lesson from Joseph Marques on this; he gave me a very short and easy way to remember the rules of these three types of JOINs. It was such an elegant way to explain it that I promised myself I would write it down so I don't forget it, so here it goes (again, I'm sure everyone knows this, and I'm sure I was even told this myself at some point in the past, but of course, I don't remember):

JOINs can be thought of in the context of a Venn diagram. You have two circles A and B. These circles partially overlap. (circles A and B represent your table data - when you join the two circles/tables together, the overlap represents relationships between the data.)

• The overlap is the INNER join - it contains only the elements in A that also have associated B elements.


• The A circle is the LEFT join - it contains all A elements regardless of whether they have associated B elements.


• The B circle is the RIGHT join - it contains all B elements regardless of whether they have associated A elements.

Note: A LEFT or RIGHT JOIN are OUTER JOINs - sometimes you see these specified as "LEFT OUTER JOIN" or "RIGHT OUTER JOIN". Looking at the Venn diagram you can see why - they include the data outside of the inner overlap area (but also including the inner data). If you just see the word "JOIN" without a specifier, it typically is referring to an "INNER JOIN".

Below is an example complete with this Venn diagram visualization:

I have a Person table containing three people: John, Mary and Bob. I have a Phone table containing three phones that have extensions of 987, 555 and 123. John and Bob have been assigned phones (I can call John on extension 987, Bob on extension 123). Mary is not assigned a phone. The phone with the extension 555 is not assigned to any person.

The INNER join:

select name,dial_number
from person
inner join phone on person.phone_id=phone.phone_id

returns results as found in the overlapping area (John:987 and Bob:123).

The LEFT join:

select name,dial_number
from person
left join phone on person.phone_id=phone.phone_id

returns results as found in the entire left circle (John:987, Mary:null, Bob:123). Because the left table is the Person table, I have one row for each person, regardless of whether they have a phone assigned or not.

The RIGHT join:

select name,dial_number
from person
right join phone on person.phone_id=phone.phone_id

returns results as found in the entire right circle (John:987, null:555, Bob:123). Because the right table is the Phone table, I have one row for each phone, regardless of whether a person is assigned a phone or not.

I don't know why it is so hard for me to remember this - it's so obvious when you see it written down like that. But, nevertheless, I find it helpful to refresh my memory with that Venn diagram explanation whenever I experience a brain freeze while developing queries.

Java Decompiler For Java5 and 6 - A Jad Replacement!

A few years ago, JAD was the Java Decompiler everyone used. However, it's essentially a dead project now - if you still have it, you'll know it can only decompile Java 1.4 class files.

However, the good news is that a new Java decompiler has come along to take its place - JD. I used this on Windows before, but I'm now on Fedora 11 and I never installed this new Java Decompiler there.

Thanks to Ian's blog, it took me less than 5 minutes to install the JD Java decompiler and its GUI front end (JD-GUI) on my F11 64-bit box. I had to issue this yum command, as per Ian's instructions, to get some libraries installed needed by JD-GUI:

yum install libcanberra-gtk2.i586 PackageKit-gtk-module.i586 gtk2-engines.i586

I then just un-tar'ed the JD-GUI download and it ran fine.

I also took the time to install the JD-Eclipse plugin for my Eclipse 3.5. That worked flawlessly on my first attempt.

So now I have a nice Java decompiler on my F11 box, both as a standalone GUI and as an Eclipse plugin.

Byteman Plugin Revisited

A couple of months ago, I came across Byteman and liked it so much, I wanted to see how easy it would be to manage it, so I wrote a quick RHQ agent plugin prototype for it and blogged about it.

Since I had some time over Christmas, I decided to revisit that prototype and build it out further. The finished product can probably be considered a good 1.0 version of a fully featured RHQ Byteman plugin.

With this RHQ-Byteman integration, you can now do remote byte-code injection into any Java virtual machine that has a Byteman agent running inside of it. Simply write your Byteman rules, store them in one or more scripts and file-upload those scripts from your browser to the RHQ Server. The RHQ Server will then stream down those script files to the remote Byteman agent, which then injects the code directly in its Java virtual machine. It is extremely easy to run a VM with Byteman inside of it - all you need is to pass a -javaagent VM argument to Java when you start it; something like:

-javaagent:/opt/byteman/lib/byteman.jar=listener:true

The uses for this kind of thing are boundless - from tracing how long it takes for a Java method to execute to testing an application's fault tolerance by forcing test exceptions to be thrown. In the future, I plan on attempting to write an extension to the Byteman plugin to allow me to trace JDBC calls and create reports based on the data I get back. In fact, work on that has already begun; the bulk of the RHQ plugin code is already written, I just have to figure out how to write the proper Byteman rules to get it to do what I want. Once I complete this "JDBC Trace" RHQ agent plugin, I'll blog/demo it.

If you are interested in this new RHQ integration with Byteman, watch the flash demo.

Note that in order to finish this Byteman plugin, I had to add some additional capabilities within Byteman itself. The bulk of the changes manifested themselves as new API methods to the Byteman client - the "Submit" class. These new features allow Byteman to be easily managed, not just by RHQ, but by any management tool that wants to integrate with Byteman. I committed this new code to Byteman's SVN repository which should make these new features available in its next release. Because the new Byteman is not released yet, nor available in the JBoss maven repository, I placed the RHQ Byteman plugin code in its own git branch. Once the next Byteman version is released, I'll merge my code into RHQ's master branch.

New RHQ Beta Release Is Out!

The RHQ project is pleased to announce the first developer release of the RHQ 1.4.0 management platform. This developer release, 1.4.0-B01, provides an early look at the new features which are being planned for the 1.4.0 general release.

Note that we've pulled in the Jopr plugins into this RHQ release. So, consider this new RHQ release a merging of both the RHQ project and the Jopr project.

Note: do not upgrade any existing Jopr or RHQ installs with this build! Specifically, the Jopr plugins in this new RHQ build are versioned differently and will not upgrade your existing Jopr plugins. We'll fix this in a later release.

Now, here are the particulars if you are interested in learning more:

• To find out the new features that are being introduced, read the Release Notes


• You can download the software


• You can get the source code from the new git repository on fedorahosted


• Feel free to ask any questions you have in our chat room at #rhq on irc.freenode.net


• If you have questions on how to use RHQ, you can ask them on our rhq-users mailing list


• If you have questions on how to develop new enhancements/fixes for RHQ or how to write RHQ plugins, you may ask them on our rhq-devel mailing list


• RHQ bugs/enhancements are now found in BugZilla


• Individual Maven artifacts have been published to the JBoss maven repository mostly under org/rhq/ (but some JBoss plugin related things are under org/jboss/on/)


• As usual, the user documentation can be found on the RHQ user documentation wiki space


• Design documentation can be found on the RHQ design doc wiki space

RHQ Server Plugins - Innovation Made Easy

RHQ is introducing a major new feature - server plugins. I know what you are saying... "ho-hum, another 'plugin mechanism'". It is true that this is analogous to the RHQ Agent plugin functionality - just as you can write your own agent plugins to extend the types of resources an agent can manage, you now have similar capabilities in the RHQ Server.

But when you examine the capabilities of this new server plugin subsystem, you will notice that you now have access to the full breadth and depth of functionality that the core RHQ Server code has, without having to modify core code. Using server plugins, you can plugin your own management code to the RHQ Server, allowing you to add to the existing core management feature set. With a minimum of a single Java POJO class bundled with an XML descriptor, you can now extend RHQ server functionality in areas you couldn't with the agent plugins. The ability to innovate new features and capabilities will be much easier.

I put together a demo for an illustration of the potential that server plugins open up. If you are interested, the demo's plugin code can be found here. This sample plugin has a single Java POJO and an XML plugin descriptor.

The core of the server plugin container infrastructure is checked in. More work will be done to enhance it further, but it works today. What the RHQ team is currently working on is adding support for different types of server plugins.

For example, the demo mentioned above uses a "generic plugin" - that is just one type of server plugin. This is a "catch-all" type of plugin - all other plugin types will essentially build on top of the same capabilities of a "generic plugin". This generic functionality allows for the server plugin developer to write Java code that gets embedded in the server and runs. Each plugin can define a plugin component (much like an agent resource component in an agent plugin). The plugin component is notified when lifecycle events occur (such as when the plugin is started and stopped). The generic plugin can also utilize the server's scheduler to run jobs on a periodic basis. For example, if I want to generate management reports, I can write a server plugin that has a job that runs every day, generating reports when it runs (in fact, this is what the demo above illustrates).

Other types of plugins that are actively being developed are:

• Content Plugins - these will allow you to define remote content repositories so you can pull in software from those remote locations to be pushed out to remote machines.


• Alert Plugins - these will allow you to plug in remote alert destinations. Heiko has some great ideas on this and has already demoed a few of them. The one I like in particular is the alert plugin that integrates with Mobicents so when an RHQ alert is triggered, a voice message is sent to an administrator's phone. Very cool :)


• Perspective Plugin - this is an extremely powerful type of plugin that will enable a developer to add additional graphical user interfaces to the core RHQ Server. There is a entire perspectives design, which will build within the server plugin infrastructure.
  

A lot more will be communicated about these server plugins as they are built out. But you can still do server plugin development today. Documentation is available, and we'll be building out more documentation as we get further along.