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 “java.net.*” and “java.io.*” 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.


Jazoon 2010 – Testing-related Talks

Jazoon 2010 is history. What remains is the surprise in the eyes of the speakers of the two testing related talks: Full house, one talk had all the seats occupied and the other almost, just a few seats remained empty. Seems like testing gets more attention.


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 {
    textBuffer.append(s);
  }
} 

The textBuffer can be reset in the startElement method.


New adventure: try to help out with JSFUnit’s static analysis package

It itches too much, so I am trying to scratch.

I have joined the JSFUnit team to help out with the static analysis package. One of the special features of JSFUnit has been orphaned for some time.


NPE comparing BigDecimal objects?

After having learned that equals() is not equal enough (my other post) I just replaced equals by compareTo. After studying the Javadoc for BigDecimal.compareTo I did not expect any problems… until some Boundary-value analysis occurred and there the NPE-issue was raised… What a NPE in a simple comparision?

A quick look into the compareTo code showed, what research into the Javadoc confirmed, even though not at the expected place.
The Javadoc for BigDecimal.compareTo(java.math.BigDecimal) did not reveal any pitfalls or precoonditions. Neither did the Javadoc for Comparable.compareTo(T). Nothing about preconditions…
Only in the class-javadoc for Comparable an innocent sentence revealed the source of the problem. Whereas in other places null is just a special case of an Object, Comparable follows this credo:

Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.

So another lesson learned. A pity that this precondition is not documented somewhere. NullPointerException obviously is a RuntimeExcpetion and as such does not need to be documented. But when a method should repsond with such a runtime expcetion to a precondition, this behaviour should be documented as a precondition to the method.


When equals() is not equal enough

The other day we were struggling doing comparisions with BigDecimals in a distributed application with BigDecimals originating from different sources. As we had learned we used equals() to compare the objects and even though everything seemed correct, even in the debugger, the logic that indicated an equality condition never was executed.

Check these two methods, and try to predict the outcome:

  private void sample1() {
    BigDecimal one1 = new BigDecimal("1");
    BigDecimal one2 = new BigDecimal("1.000");

    System.out.println("Comparing new BigDecimal(\"1\") and BigDecimal(\"1.000\"):");
    if (one1.equals(one2)) {
      System.out.println("  equals() indicates equality...");
    } else {
      System.out.println("  equals() indicates different values...");
      if (one1.compareTo(one2) == 0) {
        System.out.println("    but comparesTo() thinks the two BigDecimals are equal.");
      } else {
        System.out.println("    and comparesTo() thinks the same.");
      }
    }
  }

  private void sample2() {
    BigDecimal one1 = new BigDecimal(1);
    BigDecimal one2 = one1.setScale(3);

    System.out.println("Comparing new BigDecimal(1) and BigDecimal(1).setScale(3):");
    if (one1.equals(one2)) {
      System.out.println("  equals() indicates equality...");
    } else {
      System.out.println("  equals() indicates different values...");
      if (one1.compareTo(one2) == 0) {
        System.out.println("    but comparesTo() thinks the two BigDecimals are equal.");
      } else {
        System.out.println("    and comparesTo() thinks the same.");
      }
    }
  }

Looking into the Javadoc (Java 5) of BigDecimals gave a first hints:

Note: care should be exercised if BigDecimal objects are used as keys in a SortedMap or elements in a SortedSet since BigDecimal’s natural ordering is inconsistent with equals. See Comparable, SortedMap or SortedSet for more information.

and

Compares this BigDecimal with the specified Object for equality. Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method).

That definitely was a bit unexpected, but at least documented.


Follow

Get every new post delivered to your Inbox.