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.
June 29th, 2008 at 7:34 am
Hi Richard,
I’m always keen to improve Jetty’s integrations with 3rd party libs such as Terracotta, and I’d be interested to hear the areas that you feel need some extra attention to bring it to a par with Tomcat/Terracotta - or even beyond
regards
Jan
June 29th, 2008 at 4:43 pm
Hi Jan,
I think the main problem was the use of ConcurrentHashMaps where you didn’t really need them; I was seeing lots of lock classes being distributed because of it. However I’m not really an expert on this and you may want to talk to gbevin on the terracotta forums (http://forums.terracotta.org/forums/user/profile/333.page) as he works for terracotta and knows more about it than I do.
Cheers,
Richard
July 4th, 2008 at 1:11 pm
Hi Richard,
I am also using Wicket/Terracotta/Jetty and so I really want to thank you for your effort! I am going to adopt this implementation as well!
@Jan: I also feel that Jetty’s TC support would benefit of some improvements (talking about tim-jetty-6.1.4-1.1.0). The synchronization of org.mortbay.terracotta.servlet.TerracottaSessionManager is quite bad as it is using synchronized(this) and two ConcurrentHashMaps. This approach requires a considerable amount of TC transactions. I think, the terracotta session manager would benefit of a simpler approach using a single ReentrantReadWriteLock and two ordinary HashMaps.
regards
Stefan
July 4th, 2008 at 1:18 pm
Stefan,
If you are using wicket and terracotta then I recommend that you keep an eye on this thread on the wicket forums (http://www.nabble.com/Terracotta-integration-td18168616.html) where I am attempting to work on some improvements to the wicket / terracotta integration.
Cheers,
Richard