Richards Blog

How to run terracotta as a service

I’ve blogged about terracotta before and if you want to find out more about it I suggest you start on their website.

One thing that terracotta doesn’t provide out of the box is a way of running as a background service. While it is pretty easy to run the command in the background with a combination of & and nohup on linux e.g.:

~> nohup start-terracotta-command.sh &

However this doesn’t provide all of the functionally that you might want, like automatic restarts or remote management with JMX. It also doesn’t work on windows (if you care about that).

Luckily it is pretty simple to integrate terracotta with the java service wrapper which is an open source library to run any java program as a service. These are the steps I used to get it working:

1. Create an environment variable that points to your terracotta install directory, I use $TERRACOTTA_HOME.
2. Extract the correct version of the service wrapper for your platform inside $TERRACOTTA_HOME, my version was wrapper-linux-x86-32-3.3.0.
3. Edit your $TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/conf/wrapper.conf so it looks something like this:

   wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
   
   wrapper.java.classpath.1=../lib/wrapper.jar
   wrapper.java.classpath.2=../../lib/tc.jar
   
   wrapper.java.library.path.1=../lib
   
   wrapper.java.additional.1=-server
   wrapper.java.additional.2=-Dcom.sun.management.jmxremote
   wrapper.java.additional.3=-Dtc.install-root=../../
   
   wrapper.java.initmemory=256
   
   wrapper.java.maxmemory=256
   
   wrapper.app.parameter.1=com.tc.server.TCServerMain
   wrapper.app.parameter.2=-f ../../tc-config.xml
   
   wrapper.logfile=../logs/terracotta.log
   

   Of course you can customise most of these options fit your requirements (for example memory options or log file) or add additional parameters. Also in the conf file there are other options which you may want to look at such as logging level.

4. Edit your $TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/bin/testwrapper so it looks something like this:

   APP_NAME="Terracotta 2.6.2" 
   APP_LONG_NAME="Terracotta 2.6.2"
    
   WRAPPER_CMD="$TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/bin/wrapper"
   WRAPPER_CONF="$TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/conf/wrapper.conf"
    
   PIDDIR="$TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/"

5. You should also rename $TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/bin/testwrapper to a sensible name e.g. $TERRACOTTA_HOME/wrapper-linux-x86-32-3.3.0/bin/terracotta-wrapper.
6. You can optionally move this terracotta-wrapper file to a different location, for example /etc/init.d/ on linux.
7. Thats it. To run use this:

   /etc/init.d/terracotta-wrapper start

   To stop use this:

   /etc/init.d/terracotta-wrapper stop

   You can use ‘restart’ to stop and start the service, ’status’ to see the status of the service and ‘dump’ to take a thread dump of the running java program.

8. Anything sent to System.out will be logged to the text file defined earlier (wrapper.logfile)

These instructions are only the basic ones needed to get up and running and I recommend that you read through the service wrapper docs so that you get the system that fits best with your requirements.

Please let me know if this is of some use to you, or if you have any other ideas on how to run terracotta as a service.

In the brain of Ari Zilka

Last night I attended a free session at skills matter by the terracotta founder and cto Ari Zilka.

While I was already a terracotta user it was useful to see some other terracotta use cases, apart from http session clustering.

After the session at the pub (where else ) I got to talk to Ari about my wicket issues (see my previous post), although I had actually been having a conversation on the terracotta forum with him about it anyway.  Regardless I think its always nice to be able to put a face to someone you have been conversing with on the internet.  It was interesting to hear about the super large scale systems that he has worked on in the past.  I also learned one of the tricks how to sell software in China, which I’m sure will come in handy one day.

I would also like to thank they guy who paid for the drinks, but as I’m terrible with names I managed to forget yours.  Thank you anyway.

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.

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)