Tag Archives: java

Ehcache Configuration

In real world applications it’s common to cache some complex operations to get better performance. Caches are used in web service or database calls that aren’t expected to change its result for a long time1. There are some cache libraries, one of the most used in Java is Ehcache. We’ll se how to set up Ehcache with Spring in this post.

A dummy Spring service

Let’s create a dummy service that returns the number of time it’s been called.

public interface MyService {

	int timesCalled();

}
@Service("myService")
public class MyServiceImpl implements MyService {

	private int count = 0;

	public int timesCalled() {
		return ++count;
	}

}

In our main method we call it several times.

System.out.println("Times called: " + myService.timesCalled());
System.out.println("Times called: " + myService.timesCalled());
System.out.println("Times called: " + myService.timesCalled());
System.out.println("Times called: " + myService.timesCalled());
System.out.println("Times called: " + myService.timesCalled());

If we execute it we’ll get the expected output:

Times called: 1
Times called: 2
Times called: 3
Times called: 4
Times called: 5

Set up xml stuff

First of all we configure Spring to use eCache as a cache provider.

	<cache:annotation-driven cache-manager="cacheManager" />

	<bean id="cacheManager"
		class="org.springframework.cache.ehcache.EhCacheCacheManager"
		p:cache-manager-ref="ehcacheManager" />

	<bean id="ehcacheManager"
        class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
        p:config-location="classpath:ehcache.xml" p:shared="true"/>

In the first line we’re telling Spring that a cache will be used, with a bean called cacheManager.

In lines 3 to 5 we’re setting up that cache bean by using the Spring eCache manager, with another bean called ecacheManager.

Finally in lines 7 to 9 we’re creating that bean using a configuration file called ecache.xml. In this file we’ll set up our cache.

Our ehcache.xml:

    <diskStore path="java.io.tmpdir/QuickEhcache" />

    <defaultCache eternal="false"
        maxElementsInMemory="1000"
        overflowToDisk="false"
        diskPersistent="false"
        timeToIdleSeconds="0"
        timeToLiveSeconds="600"
        memoryStoreEvictionPolicy="LRU">
            <persistence strategy="localTempSwap" />
    </defaultCache>

    <cache name="myCache" eternal="false"
        maxElementsInMemory="100"
        overflowToDisk="false"
        diskPersistent="false"
        timeToIdleSeconds="0"
        timeToLiveSeconds="300"
        memoryStoreEvictionPolicy="LRU">
            <persistence strategy="localTempSwap" />
    </cache>

On the first line we’re setting the hard disk directory were the Ehcache will store cached information. In this case we’re using a directory called QuickEhcache inside the O.S. temporary folder (i.e. in linux /tmp/QuickEhcache).

Nest we’re setting up two caches: the default cache and a named one. I’ll explain the default cache later. The important things about this configuration are:

  • timeToIdleSeconds is the time an element can exist in the cache without being called. The default value is 0, it means no time to iddle, it lives forever.
  • timeToLiveSeconds is the time an element can exist in the cache regardless of the use. The default time is also 0, it means it lives forever.
  • eternal. If this option is set to true it’ll override the time to iddle and the time to live. The cache would live forever.
  • maxElementsInMemory is the number of elements that will be stored in the computer memory before using the hard disk.
  • memoryStoreEvictionPolicy: Policy would be enforced upon reaching the maxElementsInMemory limit. LRU means Least Recenly Used.
  • persistence is the persistence strategy to be used. localTempSwap is used to store elements in hard disk that will be deleted after a restart. With none the hard disk wouldn’t be used.

Caching the service

We have to use the @Cacheable annotation to tag a method to be cached. We will use it on the implementation class:

@Cacheable(value="myCache")
public int timesCalled() {
return ++count;
}

Now the execution is different:

Times called: 1
Times called: 1
Times called: 1
Times called: 1
Times called: 1

The service is called once, the result is stored by Ehcache and it’s served every time the service is called again. If you set a breakpoint on timesCalled you see that it is reached only once.

In our configuration we have two cache configurations, myCache and the default one. With this annotation, passing “myCache” on the value attribute, we’re using the first one. If value is not set, ehcache will usse the default cache configuration.

You can have more cache configurations. For example, if you want to cache a Web Service and a DAO you probably want different settings, so you can create a wsCache and a daoCache configurations on ehcache.xml.

On other post I’ll explain more caching options. You can get a full example on my github repository.

  1. “A long time” may not mean the same for a computer []

How to use CountDownLatch

Sometimes we need to synchronize the results of several threads running simultaneously, we need to run some task once some others have finished. We can use CountDownLatch class to do this.

The Pizza Example

Let’s use another silly example. I want to have pizza for dinner, so I’m going to cook it. While the oven is preheating (it takes 5 min) I can prepare the pizza itself (it takes 2 min). Once everything is ready I can put the pizza inside the oven. That’s easy: as the oven takes longer to get preheated than me to get the pizza ready, I can put the pizza inside as soon as the oven is ready. There’s no need to synchronize threads…

But sometimes I turn on the radio and the music distracts me. In this case it takes me to prepare the pizza from 4 to 7 minutes. We don’t know which process will finish first, we have to wait until both processes have finished to put the pizza in the oven.

final CountDownLatch latch = new CountDownLatch(2);

Thread preheat = new Thread() {

	@Override
	public void run() {
		// The oven takes 5 minutes to get ready
		// (we use 5 seconds instead)
		try {
			Thread.sleep(5000);
			System.out.println("The oven is ready.");
		} catch (InterruptedException e) {
		} finally {
			latch.countDown();
		}
	}
	
};

Thread preparePizza = new Thread() {

	@Override
	public void run() {
		// It takes me from 4 to 7 minutes to prepare the pizza
		Random random = new Random();
		int time = random.nextInt(3000);
		try {
			Thread.sleep(4000+time);
			System.out.println("The pizza is ready.");
		} catch (InterruptedException e) {
		} finally {
			latch.countDown();
		}
	}
	
};

preheat.start();
preparePizza.start();

try {
	latch.await();
	System.out.println("The pizza is in the oven.");
} catch (InterruptedException e) {
}

First of all we’re starting a CountDownLatch instance. We pass the number 2 as an argument to the constructor to tell it that there will be two processes to wait for.

Next we create a thread for the oven, the sleep simulates the preheating process. We’re using seconds instead of minutes so the program won’t be idle for such a long time.

Next we create the preparing pizza thread. With a random number we simulate the distracting song from the radio. At the end of both processes there is a line, latch.countDown(), that tells the CountDownLatch that the process has finished. You may have noticed that latch.countDown() is in the finally block. We want it to be executed no matter what exception is thrown. If the program never reaches this line it’ll hang!

Next we start both threads and tell the latch to wait for them. This is accomplished with the latch.await() line. It’ll suspend the main thread until both processes have finished (when latch.countDown() is reached).

After running this program we get something like this:

The oven is ready.
The pizza is ready.
The pizza is in the oven.

But we could also get:

The pizza is ready.
The oven is ready.
The pizza is in the oven.

Regardless of how long it takes me to prepare the pizza, “The pizza is in the oven.” won’t be shown until both tasks have finished.

How to use CyclicBarrier

Sometimes we need to run several threads at once, make them start at the same time. The Java API provides us a class, CyclicBarrier, to accomplish this.

The Race Example

Let’s assume you have to create a silly program that simulates a car race. The semaphore (our CyclicBarrier) waits for all drivers to be ready to go green, then every driver drives until they get to the finish line.

First of all, the Driver class. It will have two variables: the driver’s name and his best lap time.

class Driver {
	
    private String name;
    private Double bestTime;

    public Driver(String name, Double bestTime) {
        this.name = name;
        this.bestTime = bestTime;
    }

    //getters & setters...
}

Next we’ll create a drive method. It represents the driver driving and it will last the time the driver takes to complete a lap. Finally, if the lap time is better than his best time, the bestTime variable is updated.

public void drive() throws InterruptedException {
    System.out.println(name + " starts running!!");
    Double lapTime = getLapTime();
    Thread.sleep(Math.round(lapTime*1000));
    System.out.println(name + " finished in " + lapTime + " seconds.");
    if (lapTime < bestTime) {
        System.out.println(name + " has beaten his best time!!");
        bestTime = lapTime;
    }
}

As you can see, we need to implement the getLapTime() method. As drivers aren’t machines, they don’t perform the same time every lap, so it will return a random number around their best time. The gap is 1 second, they can beat their best time up to 1 second or take a worse time up to 1 second too.

    private Double getLapTime() {
        Random r = new Random();
        return bestTime + r.nextDouble()*2 - 1;
    }

Driver class is ready. Now we want to use each driver in a different thread so they race at the same time. We’ll create three drivers, use them on three threads, and we’ll use CyclicBarrier to make them wait until every driver is ready.

In this example, their best performance are around 13 seconds (it’s a short circuit). Every driver arrives to the grid 2.5 seconds later than the last one, so the semaphore won’t go green until the last driver arrives, 5 seconds later than the first one.

String[] names =  {"Ayrton", "Michael", "Niki"};
Double[] bestTimes = {13.21, 13.03, 13.25};

final CyclicBarrier semaphore = new CyclicBarrier(3);

for (int i=0; i<3; i++) {
    final Driver driver = new Driver(names[i], bestTimes[i]);
    Thread t = new Thread() {
        public void run() {
            System.out.println(driver.getName() + " is ready.");
            try {
                semaphore.await();
                driver.drive();
            } catch (InterruptedException | BrokenBarrierException e) {
            }
        }
    };
    t.start();
    Thread.sleep(2500);
}

When we create the CyclicBarrier, our semaphore, we pass to the constructor the number of threads it’ll wait until it starts them all. Then we create a thread that will be suspended. The key is the semaphore.wait(), every following line of code won’t be executed until the CyclicBarrier starts the thread.

To get in the pool of the CyclicBarrier, we have to start the thread as usually. Finally we make the main thread sleep for 2.5 seconds before creating the next driver.

After running this program we’ll get something like this:

Ayrton is ready.
Michael is ready.
Niki is ready.
Ayrton starts running!!
Michael starts running!!
Niki starts running!!
Niki finished in 12.790270035868033 seconds.
Niki has beaten his best time!!
Ayrton finished in 13.484038866959247 seconds.
Michael finished in 13.909761762654298 seconds.

The first three lines will take 5 seconds to get printed, with a 2.5 seconds gap between them. But as soon as Niki is ready, we’ll get the following 3 lines, the racing start. This happens even though the main thread is suspended for another 2.5 seconds. They’re running on their own threads.

Despite of being the last one to arrive to the grid before the race, Niki wins the race after 12.79 seconds!

You can get the complete sourcecode on my GitHub project.

Adding a custom jar as a maven dependency

Using maven in a Java project is great. It manages builds (as customized as you may need), executions, dependencies… In fact, dependencies is, in my opinion, the key feature of maven. Whenever a dependency is added to a project, maven will search for it at repositories, download it and store it, tagging versions.

Some weeks ago I had to get an old project without maven and make it work with it. Everything went right at first: I had only to search for the correct dependency on the repository and config my project to get it. But suddenly I found a jar that wasn’t available on the repository: it was a custom generated jar to include some fonts that were being used by Jasper on a pdf generation.

I had to get it working without adding the jar to the repository. I got some working solutions:

Adding a system dependency

  <dependencies>
    <dependency>
      <groupId>groupId</groupId>
      <artifactId>artifactId</artifactId>
      <version>1.0</version>
      <scope>system</scope>
      <systemPath>${basedir}/lib/xx.jar</systemPath>
    </dependency>
  </dependencies>

I wouldn’t do it. System scope was created to add dependencies that once where external libraries but now are packed into the JDK. Also, the Assembly plugin ignores this kind of dependencies and it doesn’t pack them with the others.

Creating a maven repo inside the project

The idea is to create a maven repo that runs on our own computer instead or a remote server. Every file needed would be on the version control system so every developer can build the project once it is downloaded.

Three steps are needed to accomplish this:

1. Add the local repository to the project pom:

<repositories>
  <repository>
    <id>my-local-repo</id>
    <url>file://${basedir}/my-repo</url>
  </repository>
</repositories>

In this case the repository will be stored on a directory called “my-repo” and it will be located in the project root directory.

2. Install jar in the repository through install-plugin.

On maven 2.2:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
-Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

On maven 2.3 and onwards:

mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

There are several options to be filled on the command:

  • path-to-file: the path to the file of the artifact to install.
  • myGroup, myArtifactId, myVersion: the group, artifact name and version of the artifact to install.
  • myPackaging: the packaging of the artifact (ie: jar).
  • path: the path to the local repo.

3. Add the dependency to the project as usual.

After running the command of the second step, several files will be created on the local repository (like pom and checksum files). This is the reason I don’t like this solution, I find it ugly with those files added to the VCS.

Installing the jar by using install-plugin

The idea is to store the jar into a project directory and install it into the m2repo directory (where all mvn dependencies are downloaded to) on build time. To get this working the dependency should be added to the repository1 as usual, and also add the plugin to the pom configuration:

    <plugin>
	    <groupId>org.apache.maven.plugins</groupId>
	    <artifactId>maven-install-plugin</artifactId>
	    <version>2.4</version>
	    <executions>
	        <execution>
	            <phase>initialize</phase>
	            <goals>
	                <goal>install-file</goal>
	            </goals>
	            <configuration>
	                <groupId>myGroupId</groupId>
	                <artifactId>myArtifactId</artifactId>
	                <version>myVersion</version>
	                <packaging>jar</packaging>
	                <file>${basedir}/lib/xxx.jar</file>
	            </configuration>
	        </execution>
	    </executions>
	</plugin>

This is the solution I decided to use on the project I was working on. It’s clean and it’ll work from the first moment a new developer downloads the project from the VCS.

  1. I mean the source code repository: SVN, GIT or whatever you use. []

String concatenation performance in Java

There are (at least) three ways to concatenate several String objects in Java. Given the strA and strB String objects, those three ways are:

  1. strA + strB
  2. strA.concat(strB)
  3. new StringBuilder(strA).append(strB)

What’s the difference? In this case, not much. The + operation internally calls to StringBuilder.append, and all is about creating char arrays (char[]). The real problem here is working with String literals (instead of variables). Apparently StringBuilder works better with Java String Pool, so it finally creates only one String object to build the entire concatenation. On the other hand, + and concat create a new String every time they are called. So:

String str = "Hello, " + "my " + "name " + "is " + "Javier.";

internally creates ¿4? ¿5? String objects to actually build one, leaving almost every one of them waiting for the garbage collector. However

String str = new StringBuilder("Hello ").append("my ").append("name ")
    .append("is ").append("Javier.").toString();

just creates the String object we want to use.

It’s not a big deal, is it? Let’s change it to:

for (int i=0; i<100; i++) {
    String str = "Hello, " + "my " + "name " + "is " + "Javier.";
    //Do some stuff with str
}

Now we have lots of variables waiting for the garbage collector.

Maybe all of this is not that important… it’s possible that the people from Sun Oracle created a very smart compiler that optimizes those operations.

Bonus: How about String.format?

String.format is not exactly about concatenation. It lets you insert values inside a String object, by replacing placeholders. For example, we can insert a String value:

String name = "Javier";
String str = String.format("Hello, my name is %s.", name);

str should be equals to “Hello, my name is Javier.” We can achieve this result by using any of the concatenation techniques, like:

String name = "Javier";
String str = "Hello, my name is " + name + ".";

From a performance point of view, it probably would be faster by concatenating. String.format parses the original String object, looking for placeholders, and those kind of operations aren’t cheap in strings.

But sometimes I prefer it: It is more readable (for me) and it provides you a syntax to specify the formatting of the value (like precision for a decimal number value).

Anyway, I think it’s a matter of personal taste.

Update: It happened in a Real WorldTM project

My fellow ghackers1 friends discussed this topic just a couple of days this post was written. Andrés had to face some performance-sucker legacy code2; it was a String concatenation inside a nested loop… Concatenations were being executed thousands of times. The execution time changed from minutes to just 2 seconds by replacing all concatenations with StringBuilder.append. Amazing!

  1. It is not a mistake, it’s the name of our coders Mailing List. []
  2. It was probably written by me, oops. []