Richard Wilkinson’s Blog

Updated terrcotta wicket-tim

The latest version of the wicket 1.3 and terracotta integration is out (1.1.3).

The code will now automatically configure your application to use the correct page store, with a default of 100 pages history per page map.  If you need to override this value then you can override the the newSessionStore method in your WebApplication class, as in the previous version (see this post).

So in most cases all you need to do to use wicket with terracotta is include the tim in your terracotta configuration like so.

<module name="tim-wicket-1.3" version="1.1.3"/>

The next thing i’m going to be working on is wicket 1.4 support, which I should get finished before wicket 1.4 goes live.

Terracotta and Wicket (the next generation)

Edit: with the 1.1.3 release you should follow the instructions on this post.  It is no longer required for you to set up the page store yourself.

The new terracotta wicket-tim is out!

Any wicket and terracotta users will know that the previous wicket-tim had issues under heavy load, which is why some months ago I set about creating something better, with lots of help from the wicket community, especially Stefan Fussenegger, we created a new in-memory page map which can cope with high load.

To use this you will need to add the wicket-tim to your classpath, if you are using maven then add this to your pom.xml file:

	org.terracotta.modules
	tim-wicket
	1.1.1

And follow the installation instructions.

In your tc-config.xml you will need to include the wicket-tim module, you can find instructions on how to do this here and here.

Then in your wicket application class you need to use the new page map:

public ISessionStore newSessionStore() {
     return new SecondLevelCacheSessionStore(this,
       new TerracottaPageStore(100));
}

The 100 in the page store parameter is the number of pages (or versions of pages) of history to keep inthe page map, and can be set to anything you feel is appropriate.

The page map is stored in the httpsession so you will need to make sure that httpsession clustering is working correctly.  If you are using tomcat then terracotta should do this automatically.

Feedback and bug reports are welcome, particularity about the user configurable number of pages history.  If we remove this then it will be possible to use byte-code instrumentation to automatically add in the TerracottaPageStore, meaning that the wicket-tim wont need adding onto your application build path.

Richard

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.