Rocket Surgery

This past week I burned up dozens of hours trying to make JBoss AOP work in my .WAR file.  Then I realized that I didn’t have to.

I have this application that is a WAR file full of web services.  What I wanted to do was create an aspect that I could weave in to gather usage statistics on every web service called — the user, the amount of time spent, whether it was successful or not, that sort of thing — and write it to a table for analysis and reporting.  Since we use JBoss as our application and web server (and a paid support contract), I decided to try JBoss AOP which is bundled with the Enterprise Application Platform.

So, I wrote my aspect, and started trying to hook it in.  Man, what an ordeal. Read the rest of this entry »

It’s fairly common to have your continuous integration tool running on the same machine that has your source code repository. It’s also fairly common to have your development server running on that same machine as well. But what if you don’t?

At my workplace we use Hudson for continuous integration (and anyone who’s read my blog knows I’m a big fan) and Subversion (which is also awesome) for source code management. These both run on the same machine. We also use JBoss as our web/app server, but on different machines, including the web server set up for development testing. We wanted to do automatic deployment to our development JBoss upon successful completion of a build.

Read the rest of this entry »

At my workplace we’ve started writing JUnit tests to monitor our systems and the systems of the other departements. One unit test pings all the servers we talk to or administer; one does an HTTP get from all the web servers we run, as well as the servers whose web services we call; another test does a quick query against all the databases we hit. We’ve set these JUnit tests up in Hudson to run every ten minutes; one failed test makes the project go unstable, and we get notifications by email and get on top of problems before the other departments notice it. They have their own monitoring software, which is pretty good, but we aren’t given access to it, and this way we get independent confirmation of what they are checking on.

We got this idea from something similar we did at a client of mine in a previous gig. To do cascading delete referential integrity, the DBA’s needed^* to use a delete trigger. Well, any time they made a change to the underlying table, they had to take the trigger off, make the change, then put the trigger back. Guess how often they remembered to put the trigger back. Anyway, we got so tired of them forgetting this and having to fix stuff all the time, that we wrote a unit test to make sure that deletes always cascaded like they were supposed to. Anytime they didn’t, we knew they dropped the trigger, and we got on the phone and fussed at them.

So, on the agenda for our suite are other neat things, such as connecting to our Dev, QA, and Prod databases, grabbing the metadata, and looking for subtle differences like missing indexes from one environment or another. We plan to make sure that the JBoss configuration files (such as connection pool definitions, system properties, JVM memory settings, etc) match what we have saved a copy of so we can tell if someone changes the server’s configuration without telling us about it. We’ll check Java versions, OS versions, etc. Anything that is external to our apps that can affect the success of those apps, we’ll make tests for it. We’ll have executable documentation of our assumptions.

After all, the real purpose of a JUnit test is to assert that something is true; and if it’s not, you’ve got a problem. Nothing says that what you assert to be true has to be the behavior of code — it could be almost anything.

^*I seriously doubt that they had to do it that way, but that was the way they insisted on doing it.

I’ve recently been working on writing a Mbean for use in JBoss’ JMX Console. I was surprised how few pages were available that gave a step-by-step guide on how to do it. So, having gotten one working, I thought I’d share my findings on how to write a MBean for JBoss.

Problem Description

First, let’s describe the problem I’m solving in this example. JBoss provides some excellent pieces for monitoring your server’s health. One of the things I wanted to monitor was the various memory pools within the JVM (PermGen, Eden space, etc). I also needed an external monitoring to monitor this for me, and to send alerts when certain conditions are reached. This package we are using is able to read attributes from JMX Mbeans, so this was the means I decided to try using. If you go into the JBoss JMX console (at http://server/jmx-console) , and look under the jboss.system section, you will see an entry called type=ServerInfo.



If you click on it, and invoke the listMemoryPools() operation, you will see a highly useful report with ASCII graphs showing how the memory is going.
Read the rest of this entry »

…you’re asked to do something you never expected to find yourself doing. I spent several hours this past week using WireShark to analyze TCP packets going to/from a JBoss server to try and figure out why the Tomcat engine in JBoss was leaking threads. Still don’t have an answer, and I’m not really asking for help (yet), but the point is that wow was that different from writing yet another JSP page.

I guess old dogs can learn new tricks after all.