Performance monitor for free?

The other day I needed to analyze some performance issue in our web-application. A short search on the net offered a link to developer-friendly solution: a performance analyzer for free requiring only few resources. Can this be true? –> Sure is worth as try.

The download from AppDynamics Lite’s website was done immediately. Setup was also easy, just a line to add to the app-server startup script and launching a java-app. All good described on the doc-website.

Behind the trenches a Jetty-server is started which serves the info to the webclient interface and collects the data from the applications.

Using the webclient to analyze data is rather intuitive, if you are used to performance analyzing tools.

My task was to discover why a request was taking longer than the same request in a previous release. Well after some configuration of the call-graph exclusion/inclusion list I found that some 90% of the processing time was spent writing the data to the socket-stream. This puts a “infrastructural change” (java-version, app-server,…) on the table as the main suspect. As application development team, there is not much one can do about that… case closed. In this task I did not need to check on memory consumption, which is not served by this particular analyzer. Normally the amount of time spent in low-level libraries like java.* is not reported seperately, but this can be configured. In my case I had to include “*” and “*” because the exclusion of “java.*” cannot be overridden. An inconvenience that can be solved in 2 minutes… If you do not make some errors in the configuration. I screwed up that part of the config and as I had not done an export before (backup, me???) I had to reinstall the performance analyzer. 15 minutes and I was up and running again.

Tu put in a nutshell:
A usefull addition to my toolbox.

Thanks to the people at AppDynamics for putting the price tag of the lite version so exceptionally low: for free.


Java Pearls: assertNotNull() – the expert version

Recently a colleague stumbled upon this pearl doing a production code review:

 * Assert not null.
 * @param object the object
 * @param  element type
 * @return the not null object
public static  T assertNotNull(T object) {
	if (object == null) {
		assertNotNull(object, "");
		throw thisLineShouldNeverBeReached();
	return object;
 * Assert not null.
 * @param object the object
 * @param msg the msg
public static void assertNotNull(Object object, String msg) {
	if (object == null) {
		throwRuntimeException("assertion: object is null but was expected not to be null. \n"
				+ msg);

well at least it is a generic method 🙂

The commenting is also from the production code… Hell of a expert developer.

SAX parser – nasty behaviour

The other day an office colleague was looking for a strange error in his SAX-parsing class: Every now and then the data he got in his endElement() method was crippled, resulting in conversion problems.

A few searches revealed that the SAX-Api has a nasty behaviour: it does not garantee rules for buffer-handling. This is to be done by the client-application.

Instead of relying on complete data delivered to the characters method my colleague had to buffer the data hiomself. Using a bit of sample code it was an easy fix… but you first have to get the notion of this kind of reason for an otherwise seemingly unrelated problem…

This page shows the sample code that we recycled:

package some.pkg;
public void characters(char buf[], int offset, int len)
throws SAXException
  String s = new String(buf, offset, len);
  if (textBuffer == null) {
    textBuffer = new StringBuffer(s);
  } else {

The textBuffer can be reset in the startElement method.