Discussions

News: Clustering iPoint Portal with Terracotta

Bookmark and Share Get thread feed

  1. Clustering iPoint Portal with Terracotta (5 messages)

    • Posted by: Matt Brasier
    • Posted on: April 14 2008 11:21 EDT
    iPoint portal is an open source collaboration portal that supports JSR168 portlets and comes with a large number of portlets out of the box. iPoint deploys as a WAR file and stores its data in a database, using Hibernate as its persistence engine. By default it uses OSCache as a Hibernate cache. Previous attempts to cluster iPoint portal using OSCache clustering, based on JGroups have not been completely successful, due to the complex nature of the object relationships in the iPoint data model. Terracotta is an open source tool that allows objects in memory to be shared between Java virtual machines. It provides an integration with Hibernate based on its integration with EhCache. Terracotta advertises that it integrates with many applications with little or no code changes required. Terracotta also provides a method of clustering users’ HTTP session data between a set of Apache Tomcat instances. The objective of this exercise was to build a clustered set of iPoint portal instances, running on Apache Tomcat and using Hibernate with EhCache and Terracotta to provide a clustered view of the database. The clustering of users’ HTTP sessions is not in scope for this exercise, so the Terracotta integration with Tomcat was not tested. The steps required to integrate iPoint and Terracotta are described in the full article. Briefly, the steps were:
    1. Install Terracotta.
    2. Configure iPoint instances.
    3. Configure hibernate to use EHCache.
    4. Configure Terracotta.
    5. Start Terracotta and Tomcat.
    The solution required a single code change in the iPoint codebase, to refactor a section of code that uses classes from the java.util.concurrent package. Our conclusion is that Terracotta provides a very powerful and neat solution to the problem of handling clustered caches. The product integrated easily with EHCache and Hibernate with little configuration required, and there was plenty of excellent information on the web to help us develop a good understanding of Terracotta, how it works and the kinds of problems it solves. Using Terracotta to enable the clustering of iPoint portal is the best approach we have seen so far and the one that we will be recommending to our customers. Terracotta goes a long way towards making it possible to cluster applications that have not had cluster awareness built in from the outset. It is also clear, from this brief investigation, that Terracotta has many applications outside the clustered caching that we used it for.
    Reply to this

    Threaded Messages (5)

  2. JBoss Cache + Hibernate[ Go to top ]

    JBoss Cache can be used as a clustered cache for Hibernate, and is one of the caching products that ships with Hibernate. http://wiki.jboss.org/wiki/JBossCacheHibernate An easy way to get any Hibernate-backed application clustered, and with no external servers, processes or systems to set up either. -- Manik Surtani http://www.jbosscache.org
    Reply to this Reply to original

  3. JBoss Cache + Hibernate + GridGain[ Go to top ]

    In addition to JBoss Cache + Hibernate combination, which is a great way to cache-enable Hibernate-based applications, GridGain allows you to grid-enable the same application by partitioning your cached data across cluster/grid nodes. By adding GridGain into the mix you basically allow every cluster/grid node to become responsible only for a dedicated portion of data, and hence allowing to cache a lot more data, minimizing inter-cache communication, and removing any necessity for redundant data duplication within your cluster. On top of that, GridGain Affinity Load Balancing allows you to collocate your computation logic with your data which minimizes redundant data migration in the cluster close to zero. GridGain is an Open Source Grid Computing product available under the same LGPL license as JBoss Cache and integrates with it out of the box. You can see an example of JBoss Cache + GridGain combination here. Best, GridGain - Grid Computing Made Simple
    Reply to this Reply to original

  4. JGroups and OSCache[ Go to top ]

    Note that JGroups is *not* a cache, but a reliable transport to send point-to-point or point-to-multipoint messages between processes. Replicated caches (such as OSCache) can be *built* on top of JGroups. JGroups lives somewhere between messaging technologies like JMS and mere transport protocols like AMQP. Although JGroups ships with a bare bones replicated cache (ReplicatedHashMap), this was just a case study and is not the major goal of JGroups. Regarding OSCache: last time I checked, OSCache uses an old version of JGroups and I've had users report issues they found with the way OSCache uses JGroups. If you need a replicated transactional cache that works optimally with JGroups, I suggest take a look at JBossCache. Disclosure: I'm the author of JGroups and work for JBoss. Bela
    Reply to this Reply to original

  5. Re: JGroups and OSCache[ Go to top ]

    Bela, The problems that we had with the OSCache/JGroups solution were with the OSCache side of things. The problem was that when updates were made to some of the more complex relationships in the iPoint model, OSCache did not propagate the change to the other cluster nodes. I have used used JBossCache as a Hibernate cache, but only with simple data models. Matt
    Reply to this Reply to original

  6. Re: JGroups and OSCache[ Go to top ]

    Good to hear it wasn't a JGroups problem you had. It seems OSCache is not maintained any longer, but maybe I'm mistaken ... Cheers, Bela
    Reply to this Reply to original