In a typical SSL configuration for a Tomcat web server, Apache sits in front of Tomcat as a reverse proxy, and does the SSL. This was the configuration of some systems I work with. There are a number of reasons why this configuration is used, the primary one being that Apache's SSL implementation is much faster than Tomcat's. So it's not often that you would go from using this configuration to switching to a Tomcat only configuration, but that's exactly what I just did.

The reason for doing this is that we wanted to use Tomcat's NIO connector, in order to use Tomcat's comet capabilities. Setting up SSL with Tomcat is something that I had never done before, I had heard though that it was not easy. After trying to do it without really understanding what I was doing, I found that it really wasn't easy. The problem was that everything I looked at on the web talked about using the Java keytool to generate a key, so you could send a certificate signing request to your trusted authority to sign. The thing is, I already had a key, and a certificate, and the Java keytool utility that does all this key manipulation has no way of importing an existing key.

Eventually I found this utility, and was able to get things working. But, as often happens when solving these problems, I then read back over the Tomcat SSL HowTo, and now with more of an understanding of what I was doing I found a much simpler and easier way of getting Tomcat to use my existing certificate.

The trick is, rather than use a JKS repository, which is the native Java SSL certificate store, and what most of the documentation on the web talks about, is use a PKCS12 repository, which is an internet standard, and can be manipulated using standard tools such as openssl. This tool requires three files, which are easy to find from your Apache SSL configuration, one is the private key file, another is the certificate, and finally the certificate signer chain. The command to run is:

openssl pkcs12 -export -in mycert.crt -inkey mykey.key \
                        -out mycert.p12 -name tomcat -CAfile myCA.crt \
                        -caname root -chain

The name and caname arguments can be anything, they're just convenient aliases to allow later manipulation of the file. The command will prompt you for a password, this password gets set as the keystorePass in the Tomcat connector configuration. The keystoreType must be set to PKCS12. Here is my Tomcat configuration:

    <Connector port="8443" maxHttpHeaderSize="8192"
               maxThreads="150" enableLookups="false" acceptCount="100"
               connectionTimeout="20000" disableUploadTimeout="true"
               protocol="org.apache.coyote.http11.Http11NioProtocol"
               SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS"
               keystoreFile="/path/to/mycert.p12"
               keystoreType="PKCS12" keystorePass="tomcat"/>

The volatile keyword is a keyword that very few Java developers know the meaning of, let alone when they should use it. The reason for this, I believe, is that the reason why it's needed is such a complex topic that unless you've studied in detail the way CPUs use registers, cache, and the way the JVM uses stack frames, it's impossible to understand why it's needed. The other reason I think, is that it is difficult to demonstrate the consequences of not using it. That is why I came up with this little puzzle, to highlight how important the volatile keyword is.

For this demonstration, you will need a multi processor Linux 2.6 or OpenSolaris system, with Java 5 or above. It will not work on Mac or Windows. If you know why it doesn't work on Mac or Windows, please leave a comment explaining, I'd really like to know. What this does highlight though is just how complex Java concurrency issues are.

So on to the puzzle. Without executing it, try and work out what will happen when you run the following code:

public class ConcurrencyFun implements Runnable
{
    private String str;
    void setStr(String str)
    {
        this.str = str;
    }
    public void run()
    {
        while (str == null);
        System.out.println(str);
    }
    public static void main(String[] args) throws Exception
    {
        ConcurrencyFun fun = new ConcurrencyFun();
        new Thread(fun).start();
        Thread.sleep(1000);
        fun.setStr("Hello world!!");
    }
}

Most people would guess that the above code would wait for about one second, print the text "Hello world!!", and then exit. The spawned thread busy waits for str to not be null, and then prints it. The main thread, after starting the spawned thread, waits for one second, and then sets str to be "Hello world!!". Simple, right?

Now try running it (remember, only on a multi processor Linux 2.6 or Solaris system). What actually happens? On my machine, the program never exits. Why is this?

The reason is that the JVM is free to make its own copy of the str pointer available to each thread that uses it. This could come in many forms. It could be that the pointer is loaded into a register and is continually read from that register. This is what is most likely happening in our case. It could be that the pointer is loaded into the CPU cache, and never expired, even after update. Or, it is also possible that the JVM will make a copy of the pointer in the threads stack frame, to allow for more efficient memory access. Whether you understand anything I've just said or not, the point is that changes to the str field may not necessarily be seen by all threads accessing it, in our case, it will never be seen by the spawned thread.

This is where the volatile keyword comes in. The volatile keyword tells the JVM that any writes to that field must be viewable by all threads. This means that the compiled machine code may not read the variable into a register and use that multiple times, it must read it from memory every time. It also must not read it from the CPU cache, it must make sure that every read comes straight from memory. And finally, it stops the JVM from creating a local copy of the field in the threads stack frame.

So, adding the volatile keyword, like so:

public class ConcurrencyFun implements Runnable
{
    private volatile String str;
    void setStr(String str)
    {
        this.str = str;
    }
    public void run()
    {
        while (str == null);
        System.out.println(str);
    }
    public static void main(String[] args) throws Exception
    {
        ConcurrencyFun fun = new ConcurrencyFun();
        new Thread(fun).start();
        Thread.sleep(1000);
        fun.setStr("Hello world!!");
    }
}

results in the expected behaviour happening, the program waits one second, prints out "Hello world!!" and then exists.

The complexity of concurrency

There are other ways to make the above code work. For example, if in the while loop, you add some code that prints something out, you will find that it works. My guess at the reason for this is that the register storing str ends up getting used for something else, and so on each iteration, str gets read from memory. Note that this is not a real fix, it is still possible for problems to occur, and indeed on some architectures the program still will not exit. Another thing that will work is to invoke Java with the -Xint argument. This disables machine code compilation, and hence makes concurrency issues arising from registers and CPU caches much less likely. But again, it's not a solution. Using the volatile keyword is the only solution that guarantees that it will work, every time, on every platform.

For five days only, you can buy 5 user licenses of the full versions of JIRA and Confluence for only $5. This includes full support for a year, and renewal will only ever cost you $5. Furthermore, all revenue raised from the promotion goes to charity. What a great way for small teams to sneak Confluence and JIRA into their companies! It's also great for people that want them for personal use but would like a few more than 2 users.

Today I decided to have a go at diagnosing why the reversing lights on my car weren't working. I quickly worked out that the bulbs were fine, so I jumped on Google to see if I could find some information about where else problems may occur with reversing lights in a car. I found some very detailed instructions, but I had a problem. These instructions were on my computer, in my room, but I wanted to take them to my car, in my garage, and I don't have a printer. However, I do have an iPhone, so I thought I'd copy the URL into my iPhone and read the instructions from Safari. The URL however was rather long and copying by hand would have been painful, what I really wanted to do was the equivalent of copy and paste from my computer to my iPhone.

Enter Mobile Barcoder. Mobile Barcoder is a Firefox extension that allows you to generate QR Codes from Firefox. A QR Code is a 2D barcode designed to be read particularly by mobile devices. Using Mobile Barcoder, generating a barcode for the current page is as simple as hovering your mouse over the icon it puts in the bottom right corner of the window:

You can also right click on a link to generate a barcode for that link:

You can even create a barcode from arbitrary text on the page, by selecting it and then right clicking:

So I have my barcode, but what use is that to me? Enter BeeTag. BeeTag is a free iPhone App that reads QR Codes and other 2D barcodes, and, depending on the type of code, lets you act on it accordingly. For example, if it's a phone number, you can dial the number, if it's a URL, you can open it in Safari, or if it's plain text, you can save it as a memo. Scanning is as easy as taking a picture:

Having taken the picture, it will read it, and then prompt you for what you want to do next. I chose to open the URL in Safari:

Now all I need to do is wait for the iPhone 3.0 firmware with copy and paste, and I have full end to end copy/paste from my computer to my iPhone.

To save explaining a hundred times over how I proposed to Beth, I've decided to put it in a blog post, much easier that way. For those of you that aren't aware, I proposed to Beth, my girlfriend of 15 months, on Saturday, and she said yes.

So, about a month ago, my Mum phoned me while I was at Beth's place. I answered the phone and put it on speaker, and Mum told me she wanted to have a late family celebration for my birthday, saying that she and Dad would be in Sydney on the 6th of December. She said she had found a really nice restaurant just out of Lithgow, and that she had to book and pay several weeks in advance. She asked Beth and I if we were free, which we were, and so we put it in our diaries. Little did Beth know, but this was all a ploy so that she wouldn't suspect anything when I drove her up the Blue Mountains.

So, I picked Beth up at 10am from her place in Castle Hill, and we started driving towards Lithgow, taking Bells Line of Road. About 10 minutes past Bilpin, I got a really bad cramp in my leg. You know how annoying that is when you're driving? It was so bad, I had to pull over and stretch. We pulled over at a pretty ordinary place on the side of the road in the middle of nowhere.

After doing some stretches, I said to Beth "Hey, it looks like there's a nice view here, why don't you get out." So she did. As we were walking around, we noticed an unusual small pile of rocks. Being an immature guy, I decided to kick it over. She also decided to kick it, and then we noticed a very old looking piece of paper underneath. We picked it up, and it turned out to be a letter, dated 1851. The writing on it was very old fashioned, I'll scan it in sometime maybe and attach a picture of it to this post, but for now, here's the transcript. The letter was by someone who had "something", and was being pursued for it. This thing was too heavy, and he had to hide it. The letter contained instructions on how to find it.

We weren't sure how the letter got there, but thinking that there was a slight possibility that the letter had never reached its recipient, we decided to search for the treasure. We found the landscape exactly as the letter described, and soon we were at the entrance of a small overhang. There was a cross etched into the wall, and nearby we found a very old rusty shovel. So, I started digging, and before long, the shovel hit something hard. It was a treasure chest. I dug up the treasure chest, and opened it. Inside was a ring and two roses, lying in a bed of sand. As soon as I opened it, I picked up the ring, got down on one knee, and recited a poem that I wrote, which ended in "Will you marry me?". I won't attach the poem here, but if you really want to know what it said, ask me.

Beth burst into tears (this was my aim) and said yes. After that we headed back out of the valley, up to a high rock with a very nice view, where I had a picnic basket and esky with French champagne, cheese, Caesar salad, fruit and chocolate, and we had a picnic lunch.

As one last surprise for Beth, I took her out for dinner that night, telling her it was a dinner for two, but when we got there both sets of parents were there.

If you're interested in the logistics of the day, I'd been planning for about 6 months, though I didn't have a date 6 months ago, I knew that what I wanted to do would take a lot of work, so I started preparing it so that when I did decide to propose, I would already be half ready. I got up at 5:15am on the morning, drove up to the spot and planted the chest with 2 friends. I then went back to Sydney to pick up Beth while they waited up in the area. I phoned them when we were half an hour off and they went and planted the letter, and then waited for us to get there. 5 minutes off I pranked them, and they left.

Here's some more photos:

Close up of the treasure chest.

The ring.

The way down to the treasure chest was very steep and rough.

Where the chest was buried.

Many thanks to Mum, for setting up the decoy event and for writing out the letter, to Aaron and Denise, for helping me set everything up and waiting so patiently for me to pick Beth up, to Beth's parents, for arranging dinner that night and help keeping Beth completely unsuspecting of the event, to Leon Milch, for helping me design and making a beautiful engagement ring, and finally to Beth, for being the most amazing fiancée a guy could ever hope for.