Tuesday Sep 08, 2009

Profiling an ANT process

I had an opportunity recently to take a look at what was causing a significant increase in the time required for automated builds. The build system is based on Ant so what I wanted to see was a list of the top targets and sub tasks, so I could easily find the performance hotspots. I was hoping to use a performance flag that would generate this information but I didn't see anything readily accessible that would give me the information I needed. 

After looking around the ant documentation, I found the BuildListener interface which provides notifications of build events (target started, target completed ...). What I wanted to do was to implement this interface to capture the starting and ending of tasks and targets so that I could generate an ordered list of the targets consuming the most time. I created a TimingBuildListener class that does the following:

  • keep a list of the x targets that take the most time. Each target maintains the list of tasks (and their times) so that decomposition within a target is possible.
  • manage the target lists according to the current stack of running targets.
  • provide thread safety to work with the parallel task. There isn't as much documentation on how events are generated so this code was written empirically based on how Ant 1.7.1 is implemented and works for the intended project, so you may have different results. 

Once I had this code, I got this working on a simple build file (adding a build listener only required adding the fully qualified classname of the listener using the -listener command line switch as well as the lib switch to specify the appropriate classpath for the class) and progressed to profiling the full build.

The profiling information identified a problem with the way we were compressing css and html files which was taking more than 50% of the build time (that includes unit tests), so we now get continuous build results in half the time :)

Friday Nov 14, 2008

How to pass a parameter into an XSLT stylesheet

First step is to set the parameter in Java. Here is some sample code:

TransformerFactory tf = TransformerFactory.newInstance();
File transform = new File("myTransform.xsl");
Transformer t = tf.newTransformer(new StreamSource(transform)); 
t.setParameter("aParam", "value");
t.transform(new StreamSource(new File("input.xml")), new StreamResult(new File("output.xml")));⁞

Above is the basic code to get a stylesheet working, so performance could be improved by compiling the stylesheet using TransformerFactory.newTemplates. The Transformer.setParameter call is what actually passes the parameter into the stylesheet.

 The next step is to start using the parameter in the stylesheet. The parameter is treated just like an param element so this can be accessed by adding a param element as a child of the stylesheet element.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

   <xsl:param name="aParam"/>

Now this can used within the stylesheet just like a parameter. 

Monday Jan 21, 2008

Caching static resources in glassfish

I am working on a project which has a fixed daily deployment schedule, Monday through Friday there is a 9:45 deployment. I wanted to take advantage of the known deployment schedule to incorporate Cache control directives when serving static resources. Currently, Glassfish is serving the static resources so I wrote a simple Filter which I applied to the static resource patterns. The filter is instantiated when the web module loads, so the next deployment serves as the appropriate caching period (the period will vary based on the day, the Friday deployment will be cached over the weekend). 

Glassfish (as well as other servers like Apache) will set the Last Modified and ETag headers. These headers still require the client to issue an HTTP request for the resource; however, the server may respond with a 304 status code which indicates the content was not modified since the given date and etag (a mechanism for detecting change in the contents of the resource, like a hashcode). This is accomplished by the client sending the If-Modified-Since header along with the If-None-Match header to let the server know the date and "signature" of the file currently cached. The server will return a 304 if the response would return the same resource which saves the network transmission time for the resource.

This approach doesn't solve the problem where browsers generally only request two resources from the same domain in parallel, so if there are hundreds of resources on a page the overhead of determining whether the resource was current could impact the page load and hence the user experience. Instead I wanted to use the regular deployment cycle to reduce the number of requests required to determine whether resources are up to date.

The filter sets both the HTTP 1.0 Expires header as well as the HTTP 1.1 Cache Control Directive, to ensure both protocols are covered. If you are using apache to server static (or dynamic) resources you can find a good resource for setting up apache modules to do something similar on websiteoptimization.com. Glassfish has admin console capabilities for configuring caching which should be evaluated before doing everything in code.

If you want to give it a try in a web module, you will need to edit web.xml to add a filter and a filter mapping:

        <url-pattern>/images/\*</url-pattern> <!-- these patterns should match cached resources -->

Add the filter class to the web module along with adjusting the appropriate timeout.


Tuesday Aug 21, 2007

Unit Testing HTTP Calls

I have been working with RESTful web services and had the need to verify the HTTP messages I was sending were appropriate. Since I am doing this work using Java SE 6, I was able to take advantage of the httpserver package. This package provides a lightweight HTTP server and is used for things like publishing web services and displaying memory graphs based on jmap.

The code to take advantage of this is easy. As you can see below, my strategy was to get an arbitrary open port on the local machine, bind a test handler to a context where the message is directed, and then verify what was sent matches what was expected.

 InetSocketAddress address = new InetSocketAddress(0); // get free port on local machine
HttpServer server =HttpServer.create(address, 1); // create a server on the arbitrary port
int portNumber = server.getAddress().getPort(); // get the port where this is bound for the invocation
MockHttpHandler handler = new MockHttpHandler(); // create a mock handler to capture the HTTP input
try {
    server.start(); // start the server
    server.createContext("/test",handler); // create a context with the mock handler
        } finally {
            server.stop(0); // stop the server after the test is complete

Saturday Jun 16, 2007

Workaround to get more information for the JPA exception: During synchronization a new object was found through a relationship that was not marked cascade PERSIST.

I was getting a bit frustrated dealing with the JPA exception During synchronization a new object was found through a relationship that was not marked cascade PERSIST. The issue is that the message doesn't display the object in question. I wanted to grab the code and fix this issue, so here is what I did

  • download the persistence source from https://glassfish.dev.java.net/downloads/persistence/JavaPersistence.html. I am working with V1 so I used that version.
  • I copied the class I wanted to modify to my unit test area using the same package structure as in the persistence jar file. I am using NetBeans for unit testing so I adjusted the unit test classpath to put the test classpath ahead of the toplink essentials jar file which effectively replaces the class.
  • Looks like this is just a bug where the IllegalStateException thrown in RepeatableUnitOfWork line 115 (as we all know and love) is passing the object, so all that needs to be done is to fix the error message. I found ExceptionLocalizationResource where the error messages are stored and added a parameter to the new_object_found_during_comment message. I changed it to: "During synchronization a new object was found through a relationship that was not marked cascade PERSIST. {0}." This will provide the output of the toString method for the object where EntityManager.persist was not invoked. Since the toString is in the user space, this allows me to add any additional information to help figure out where to add CascadeType or call persist.

After doing this, additional information on which class (and the toString) is now contained within the exception message.

The glassfish tracking issue has been filed as https://glassfish.dev.java.net/issues/show_bug.cgi?id=3254 

Friday Jun 01, 2007

Unit Test Mantra

I just came across an interesting short and funny document on unit testing. I think the message is a good one. 

Thursday May 10, 2007

Interesting Class in J2SE 6

I was looking at the Javadoc for Java SE 6 recently and I came across the SchemaLoaderFactory javadoc. The javadoc mentions this class was not supposed to be part of Java SE. 

Friday Mar 16, 2007

Unit Testing using the Java Persistence API

I have been using the Java Persistence API  recently and I wanted to create some unit tests which did not run against the target database. Java Db which is bundled with both Glassfish and Java SE 6 is ubiquitous in my environment and supports running in embedded mode. This combination makes it ideal for mocking the database environment for unit tests.

If you look at the persistence.xml (NetBeans has a wizard to generate entity classes from a database), you will notice some properties (the properties will vary depending on the provider you are using) of the following form:

      <property name="toplink.jdbc.user" value="app"/>
      <property name="toplink.jdbc.password" value="app"/>
      <property name="toplink.jdbc.url" value="DataBaseConnectionString"/>
      <property name="toplink.jdbc.driver" value="org.apache.derby.jdbc.ClientDriver"/>

 The properties shown above are based on the TopLink provider and specify how to connect to the database. I wanted to override these properties to use an embedded database connection in my unit tests. The Persistence class provides two static methods for getting an EntityManagerFactory one of which takes a Map. The properties in the map can be used to override the properties defined in the persistence.xml file. I used a different set of properties for the connection string, user, password, and driver to support an embedded database. I also added the following property to the map:


Which will create recreate the database using the annotations. As part of the JUnit test's setup method, I would override the persistence properties, then establish a known database baseline before executing the unit tests. The combination of the ability to override the persistence manager and use an embedded database provides a nice mechanism for a cleanroom testing environment.


Saturday Feb 24, 2007

Nice summary of monitoring features in J2SE

There is an interesting blog entry by Mandy Chung on the monitoring capabilities of J2SE. Worth a look to get an overview and references to other blogs describing how to use these cool features. If you are running on windows, you might want to get the pid from the task manager to use jstack. The processes tab has a column (by default hidden) for the pid. Turn the column by selecting the processes tab,then under the view menu option use the select columns action.

Tuesday Feb 13, 2007

Guide to Suppress Warnings

I came across this guide to the values for SuppressWarnings annotation, for those few that you can't fix.

Sunday Feb 11, 2007

Difference between extends and super In generic collections

The guidelines I have been using to differentiate when to use extends v. super are the following:

  • Use extends if you need to read from the collection (i.e. List<? extends A>;). This will ensure that the collection itself contains items which extends A. This is read-only because there is no way to determine the exact type to add to the collection (the parameter could be List<B> and there would be no way of ensure the type safety of an addition).
  • Use super  if you want to write to the collection (i.e. List<? super A>;). In this case, the collection can support addition of A types as we know the specified type of the collection is a super class of A. Therefore, A typed items can always be added to the collection.

Here is some code to look at:

import java.util.List;

public class GenericTest {
    private void useExtends(List<? extends SomeInterface> l) {
        for (SomeInterface i:l) {
        // below doesn't compile because the exact type of list isn't known
        l.add(new SomeInterface(){});
    private void useSuper(List<? super SomeInterface> l) {
        // the for loop below doesn't compile as the List is one of the super
        // type of SomeInterface but unknown as to which one
        // Object could be used in the for loop
        for (SomeInterface i:l) {
        l.add(new SomeInterface(){});
    interface SomeInterface {}

Saturday Feb 10, 2007

Using the Rhino Javascript debugging APIs


This blog describes how to use the Rhino debugging APIs.
[Read More]

Wednesday Oct 25, 2006

Resource creation as part of deployment

There is currently a glassfish enhancement (https://glassfish.dev.java.net/issues/show_bug.cgi?id=670) which supports the ability to package a resource file within an archive to support resource provisioning as part of deployment. This capability is currently available via command line, where resources can be provisioned by passing the file, but this requires a seperate step which can easily be forgotten. NetBeans 4.1 introduced the concept of zero configuration deployment where creating and interaction with EE concepts such as Message Driven Beans would create and provision the resources as part of the tooling work. This feature was great and improved the user experience; however, it would nice to have this feature be a first class capability of glassfish. If you agree, please vote for this glassfish enhancement above.

Saturday May 27, 2006

Double Check locking Part 2 / Using AtomicReference

When I posted the original results of some of the solutions for multi-threaded lazy initialization, there was an additional suggestion about using the AtomicReference class. The code would be something like:
private static AtomicReference
   instance = new AtomicReference();
    public static AtomicReferenceSingleton getDefault() {
	AtomicReferenceSingleton ars = instance.get();
	if (ars == null) {
                   new AtomicReferenceSingleton());
	    ars = instance.get();
	return ars;
This approach about the same as the volatile solution (the results can be found http://blogs.sun.com/roller/page/cwebster?entry=double_check_locking. The summary is about a 3% penalty over a straight method call but about 6% better performance than fully synchronizing the methods.

Sunday May 21, 2006

Double Check locking

I attended a Java One Session TS-1630 (The Java Memory Model: The building block of concurrency) which discussed the memory model and the relationship with synchronization, volatile, and the concurrent libraries. Part of the session was of course about double check locking. The specification on the memory model as of JSE 5 has codified the volatile keyword to allow another correct solution for double check locking. I did a very rough performance check for three correct solutions for lazy initialization. The test obtained the lazily created instance 10,000,000 times and invoked a mutating method on the class. Solution 1: Initialize the value in a static block (this can be implicit)
private static ClassSingleton instance = 
new ClassSingleton();

public static ClassSingleton getDefault() {
return instance;
The VM guarantees this behavior and the code is straightforward, this method was the fastest (on my machine the test took roughly 1092 milliseconds). Solution 2: Use volatile to make the double check locking pattern work as intended.
    private static volatile VolatileSingleton instance;

public static VolatileSingleton getDefault() {
if (instance==null) {
synchronized(VolatileSingleton.class) {
if (instance == null) {
instance = new VolatileSingleton();
return instance;

The volatile keyword is used here to ensure appropriate memory consistency. This was the second fastest approach but not by much (1161 milliseconds, about 6% slower than 1). Solution 3: Use a synchronized method but not double check locking:

 private static SynchronizedSingleton instance;
public static synchronized SynchronizedSingleton getDefault() {
    if (instance == null) {
        instance = new SynchronizedSingleton();

    return instance; }

 This is also straightforward, just adding a synchronized keyword to ensure that memory will be consistent when determining if the instance is null. This technique was also the slowest (1202 milliseconds, about 9% slower than 1 and 3% slower than 2).




« June 2016