Richard Wilkinson’s Blog

More on terracotta and wicket

So recently I have been working on session clustering on Zoomf, which is written in apache wicket.

We decided to go down the terracotta route, because at the time we were running on Jetty and I couldn’t get the WADI clustering to work right, plus terracotta claimed to be easy to get up and running, which in fairness it was. All was going to plan and we deployed the code to our production site. Unfortunately we started running into problems. Basically loads of wicket objects were being created and distributed, because of the way wicket stores pages in its session. With the amount of traffic our site was getting the terracotta distributed garbage collector (dgc) couldn’t keep up, and so the persistent disk store was using up more and more disk space. We’re talking tens of gigabytes here, which is clearly a problem.

After playing around with the different terracotta config options it became apparent that a wicket solution to limit what was distributed was needed.

The simplest solution I could think of was instead of storing the wicket pages as page objects I should serialize them and store them as byte arrays instead. This proved to be as easy as implementing a new wicket IPageMapEntry which does the serialization and deserialization and overriding the getPageMapEntry() method in my base page to make all my pages use the new class.

The new class itself is really simple:

public class NewPageMapEntry extends AbstractPageMapEntry
{
        private transient Page page;
        private byte[] data;
 
        public NewPageMapEntry(final Page page)
        {
                this.page = page;
 
                data = Objects.objectToByteArray(page);
 
                setNumericId(page.getNumericId());
        }
 
        @Override
        public Page getPage()
        {
                if(this.page == null)
                {
                        page = (Page) Objects.byteArrayToObject(data);
                }
                return page;
        }
}

With any luck the new code should be running Zoomf next week and on Tomcat too (tomcats terracotta support is more mature than jettys). If are are interested seeing the progress of this you can read this thread on the terracotta forum, which was extremely useful. A big thanks to all the guys who helped me on there!

EDIT:

I am now working on a better way for to integrate wicket and terracotta, see this thread for more information.

Last week’s london wicket event

I just thought I’d talk about last weeks wicket event at google.

I gave a presentation on how to integrate google maps and wicket, and while it isn’t the definitive answer on how to do it, should give people some idea where to start.

The code can be checked out from the london wicket google code project and uses maven2 to build so you wont need to worry about those pesky dependencies, if you don’t use maven then you will need the normal wicket jar and jdom.

The slides from my presentation (plus the others too) are also available from the london wicket google group and you should also check out the london wicket website too.

Also if you are wanting to check out a real world example of google maps and wicket integration head over to the map based search page on Zoomf at www.zoomf.com/map.

Thoughts on Terracotta

Recently I’ve been working on session clustering with terracotta, jetty and wicket, so I thought I’d write about my experience.

Good points:

• It works!  This may seem a bit silly to state, but other session clustering methods I tried didn’t work and cost me time trying to get them to work.  The time I put into terracotta actually paid off.
• Good support.  Even though the guys that develop terracotta sell consultation services for it they will still help people in the forums.  From finding and reporting a bug in terracotta it was about a week before it was fixed and integrated into the nightly builds.
• Its open source.
• Its versatile, you don’t just have to use it for http sessions.
• A useful admin console for connecting to your terracotta instances (you can even do cluster wide thread dumps in the 2.6 versions).
• It just worked with wicket due to a special wicket integration module (which was included)

Bad Points:

• Lots of config.  Even after you get your system working there is still lots of performance tuning to be done to get the best out of everything (although the admin console in the 2.6 release helps with this).
• Large download (ok this isnt really a bad point in todays world of broadband and terrabyte hard discs).  Does it really need to bundle tomcat?
• Eclipse plugin kept complaining that the config xml file was not valid - it created it for petes sake (ok this is another small point, running through eclipse was very easy with the plugin)