Tomcat's Graceful Shutdown with Daemons and Shutdown Hooks

My last couple of blogs have talked about long polling and Spring's DeferredResult technique and to demonstrate these concepts I've shoehorned the code from my Producer Consumer project into a web application. Although the code demonstrates the points made by the blogs it does contain a large number of holes in its logic. Apart from the fact that in a real application you wouldn't use a simple LinkedBlockingQueue, but would choose JMS or some other industrial strength messaging service, and the fact that only one user can get hold of the match updates, there's also the problem it spawns badly behaved threads that don't close down when the JVM terminates.

You may wonder why this should be a problem…

Five Ways of Synchronising Multithreaded Integration Tests

A few weeks ago I wrote a blog on synchronizing multithreaded integration tests, which was republished on DZone Javalobby from where it received a comment from Robert Saulnier who quite rightly pointed out that you can also use join() to synchronize a worker thread and its unit tests. This got me thinking, just how many ways can you synchronise multi-threaded integration tests? So, I started counting...

Producers and Consumers - Part 3 Poison Pills

A couple of weeks ago I wrote part 2 of a short series of blogs on the Producer Consumer pattern. This blog focused upon the need to close down my Teletype’s worker thread, fixing a bug in the original code from part 1 of the series.

The idea here is that the Teletype’s worker thread can be controlled by a command from the application’s main thread. This command tells the worker thread to shutdown thus allowing the app the gracefully shutdown as demonstrated by the code below:

Producers and Consumers - Part 2 - Interrupting Worker Threads

This blog isn’t really about Producers and Consumers, I covered all that in my last blog. If you’ve not seen it then to recap it demonstrates the Producer Consumer pattern using the scenario of commentators reporting on football (soccer) games by putting updates on a queue. These updates are then read back in the TV studio by a Teletype and displayed on the viewer’s TV screen.

Producers and Consumers - Part 1

The Producer Consumer pattern is an ideal way of separating work that needs to be done from the execution of that work. As you might guess from its name the Producer Consumer pattern contains two major components, which are usually linked by a queue. This means that the separation of the work that needs doing from the execution of that work is achieved by the Producer placing items of work on the queue for later processing instead of dealing with them the moment they are identified. The Consumer is then free to remove the work item from the queue for processing at any time in the future. This decoupling means that Producers don't care how each item of work will be processed, how many consumers will be processing it or how many other producers there are. It's a fire and forget world as far as they're concerned. Likewise consumers don't need to know where the work item came from, who put it in the queue, and how many other producers and consumers there are. All they need to do is to grab some work from the queue and process it.

In the Java world, the Producer Consumer pattern is often based around some kind of blocking queue and there are several to choose from. These include ArrayBlockingQueue, LinkedBlockingQueue and PriorityBlockingQueue. Each have slightly different characteristics.

Synchronising Multithreaded Integration Tests

Testing threads is hard, very hard and this makes writing good integration tests for multithreaded systems under test... hard. This is because in JUnit there's no built in synchronisation between the test code, the object under test and any threads. This means that problems usually arise when you have to write a test for a method that creates and runs a thread. One of the most common scenarios in this domain is in making a call to a method under test, which starts a new thread running before returning. At some point in the future when the thread's job is done you need assert that everything went well. Examples of this scenario could include asynchronously reading data from a socket or carrying out a long and complex set of operations on a database.

Investigating Deadlocks – Part 5: Using Explicit Locking

In my last Investigating Deadlocks blog I looked at fixing my broken, deadlocking balance transfer sample code using both Java’s traditional synchronized keyword and lock ordering. There is, however, an alternative method known as explicit locking.

The idea here of calling a locking mechanism explicit rather than implicit is that the explicit means that it is not part of the Java language and that classes have been written to fulfill the locking functionality. Implicit locking, on the other hand, can be defined as locking that is part of the language and is implemented in the background using the language keyword synchronchized.

You could argue as to whether or not explicit locking is a good idea. Shouldn’t the Java language be improved to include the features of explicit locking rather than adding yet another set of classes to the already enormous API? For example: trysynchronized().

Explicit locking is based around the Lock interface and its ReentrantLock implementation. Lock contains a bunch of methods that give you lots more control over locking than the traditional synchronized keyword.

Investigating Deadlocks – Part 4: Fixing the Code

In the last in this short series of blogs in which I’ve been talking about analysing deadlocks, I’m going to fix my BadTransferOperation code. If you've seen the other blogs in this series, you'll know that in order to get to this point I’ve created the demo code that deadlocks, shown how to get hold of a thread dump and then analysed the thread dump, figuring out where and how a deadlock was occurring.

Investigating Deadlocks – Part 3: Analysing the Thread Dump

In my previous two blogs in this series, part 1 and part 2, I’ve demonstrated how to create a piece of bad code that deadlocks and then used this code to show three ways of taking a thread dump. In this blog I’m going to analyze the thread dump to figure out what when wrong.

Investigating Deadlocks – Part 2: Obtaining the Thread Dump

One of the most important requirements when investigating deadlocks is actually having a deadlock to investigate. In my last blog I wrote some code called DeadlockDemo that used a bunch of threads to transfer random amounts between a list of bank accounts before grinding to a halt in a deadlock.

This blog runs that code to demonstrates a few ways of obtaining a thread dump.

Investigating Deadlocks – Part 1: Creating a Deadlock

I’m sure we’ve all been there: it’s late, you’re hungry, your server has hung or your application’s running at snail’s pace, and there’s someone breathing down your neck wanting you to fix the problem before you go. One of the possible causes of your application hanging unexpectedly is a threading issue known as a Deadlock.

Without going into too much detail, threads can be in one of a number of states as shown by the UML state diagram below...

Using the Builder Pattern to Construct Thread-Safe Objects

A couple of days ago my blog described the benefits of creating immutable POJOs in order to make your programs more thread-safe. Today’s blog builds on that idea, by demonstrating the use of the Builder pattern to construct your POJO’s. It’s strange that I haven’t discussed this before as it’s one of my favourites. You can find it in more detail in Joshua Bloch’s Effective Java Second Edition - page 14.

The Telescoping Constructor (Anti)Pattern

The Telescoping Constructor is an example of a pattern that borders on an anti-pattern that is all too often used in projects even though there are better alternatives availble. In this pattern, your POJO has numerous constructors each taking a different number of parameters that, if the class has been written correctly, delegate to a default constructor.

Thread-Safe Immutable Objects

Threading problems are the most weird and difficult bugs to fix, mainly because they’re so hard to reproduce. You can mitigate some of these problem by designing thread-safe code, which isn’t so hard as you think.

The code below is an example of a thread-safe technique that's for synchronising the update of instance variables without the need for language specific locking and mutexes. The big idea is that we tie two or more instance variables together in a bean. The fields are final and obey the Java rules of only being updated table during either static initialisation or when the constructor is called.