eXo Blog – Java Middleware for Cloud Services

The core Java Content Repository functionality that we leverage in both GateIn and eXo Platform 3 is eXo JCR (developed in JBoss.org, the JBoss open source forge). We have made many improvements and introduced new features in our upcoming version of eXo JCR (eXo JCR 1.14.0-CR1). The following post provides a technical deep-dive into some of these changes.

New Features

JBoss Infinispan

The most significant of the new features found in eXo JCR 1.14 is the ability to rely on Infinispan as the underlying cache; this provides a more scalable clustering solution. For now, we only used and tested Infinispan (also known as ISPN) as an alternative to JBoss Cache (also known as JBC, which you can still use if you prefer). In other words, Infinispan is only used as a simple replicated cache, which is still interesting in terms of memory footprint and concurrency.

According to our first internal tests, ISPN seems to consume less memory than JBC; more importantly, ISPN clearly reduces the contention compared to JBC. With JBC, you can face contention issues especially when you use any eviction algorithm other than expiration, since any read access to a JBC Node will add an eviction event to the LinkedBlockingQueue instance of the whole region. In ISPN, they had the brilliant idea to implement their own version of ConcurrentHashMap, which they call BoundedConcurrentHashMap, to manage the eviction within each segment. This means that we now have one LinkedBlockingQueue instance per segment, so you can reduce the contention generated by the eviction algorithm by simply increasing the concurrency level.

Another significant improvement ISPN offers is the remove method. In our internal tests we realized that in some use cases, it could be over 800 times faster to remove a cache entry in ISPN compared to JBC. This is mainly due to the notion of Node trees in JBC that is not found in ISPN. Actually, when you remove a node in JBC, it needs to remove all its descendants – which consumes a lot of time and CPU when you have a lot of children nodes.

Next we will try to improve our ISPN integration, to fully benefit on the distributed cache capabilities offered by ISPN. In real-life scenarios, it is difficult to ask a customer to deploy their application on hundreds of instances of a given application server, since the required licenses and support would be cost-prohibitive (not to mention a nightmare for the administrator). On the other hand, it sounds more acceptable if the customer only needs to deploy their application on 3-8 app server instances; these would be used as frontal servers, while hundreds of ISPN cache instances could be deployed in standalone mode to act as the cache server. This would allow ISPN to be used as a cache server, although in our context this is not possible out of the box (due to a lack of JTA support when ISPN is used as cache server – more details here).

Java Security

As you may know, our new eXo Cloud IDE is a free developer service for Java Platform as a Service (PaaS). This ability to easily create and deploy REST components on the fly is very interesting in terms of productivity. However, it needs to be over-protected to ensure that no malicious users affect the integrity of your environment. So we made the entire eXo JCR stack rely on Java Security, meaning that when the SecurityManager is installed, access to sensitive methods is impossible unless the full call stack has enough rights.

Apache Tika

eXo JCR already has a plugin-based framework that enables the extraction of both the meta-data and the full text content of the most common document types, such as Text, XML, HTML, PDF, MS Office and Open Office documents. But we wanted to support many more types of documents, so we decided to implement a plugin for Tika. This is actually an open door to many new document types, including images, audio and video.

Other Interesting New Features…

• If you dedicate a listener for a specific event broadcast by the ListenerService, you can elect to receive the event asynchronously by adding the annotation @Asynchronous (from the package org.exoplatform.services.listener) to the class declaration level of your listener.
• eXo JCR can be deployed on Jetty.
• H2 DB is now supported.

Improvements

JCR Re-Indexing

With full text search engines such as Lucene, it is helpful to rebuild them regularly to preserve consistency, get rid of potentially corrupted indexes, and ensure optimal performance. We decided to speed up the re-indexing mechanism by making it multi-threaded, and by relying more on features specific to RDBMS, such as SQL paging. The results are quite interesting: according to the total amount of core and the db type used, the indexing of millions of JCR nodes could be 4 to 6 times faster.

Lucene Indexing in Clustered Environments

In the previous version of eXo JCR, we stored the Lucene indexes in a shared file system, so it was possible to add a node to the cluster dynamically (meaning the new node could access the Lucene indexes directly, so they could be started and made available quickly). The problem with this approach was that the performances in read and write accesses were affected, and that using a shared file system could have side effects. In addition, only the main cluster node (a.k.a. coordinator in JGroups terminology) could see the latest changes. This is because, for performance reasons, they are only persisted after a certain amount of time, while the rest of the cluster could only see the persisted changes.

To improve this, we took a new approach. Each node can see all changes in near-real time, and has its own version of Lucene indexes. This improves performance and means we no longer rely on a shared file system. This change is possible because we were able to improve the index recovery. Now, when a new node is launched that doesn’t have its own version of Lucene Indexes, you can either decide to rebuild them from a configuration (if the DB is not too big, knowing the re-indexing has been improved too) or get it from the coordinator. The latter method allows you to get a new node up and running in a reasonable amount of time, and fully benefit from having the Lucene indexes locally.

The next step will be to implement a non-blocking index recovery in order to have the new cluster node ready to use even faster.

Backup/Restore

The backup/restore feature has been completely reviewed to better fulfill the requirement of an enterprise; it is now faster, more reliable and much easier to use.

Other Interesting Improvements

• An application with a lot of workspaces requires a lot of JBC instances (3 per workspace: JCR Cache, JCR Indexing and JCR Lock). To reduce the total amount of JBC instances, you can configure your JCR to make your cache instances shareable – meaning you only need 3 JBC instances, and they can be used by all your workspaces. With this configuration, your JCR will create a dedicated JBC region per workspace instead of launching a new JBC instance.
• The way missing values are cached is optimized for applications that require frequent testing of the existence of specific nodes or properties. If the searched-for node or property does not exist, the information indicating that the data is missing in the DB is stored in the cache, instead of accessing the database at each call. Because future re-tests will find this information in the cache instead of having to query the DB, your application will be faster and more scalable.
• All cluster nodes can now be launched in parallel, even when the JCR has never been initialized. This was a limitation in the previous version, since the JCR had to be initialized first.

Download

You can download eXo JCR 1.14.0-CR1 from here and get the documentation from jboss.org here.

You can test it with jetty or tomcat; for both be sure to read the file exo-readme.txt to know how to test it with the default configuration, JBoss Cache or Infinispan. In a nutshell, you simply need to launch it from eXo batches with a new parameter: jbc for JBoss Cache and ispn for Infinispan.

The best ways to quickly test it are:

• The WebDav access available here
• The FTP access available from port 2121

For both, use the account root with the password exo.

Enjoy,
Nicolas

Share this blog post with :

Close Bookmark and Share This Page

Save to Browser Favorites / Bookmarks

Ask backflip blinklist BlogBookmark Bloglines BlogMarks Blogsvine BuddyMarks BUMPzee! CiteULike co.mments Connotea del.icio.us

Digg diigo DotNetKicks DropJack dzone Facebook Fark Faves Feed Me Links Friendsite folkd.com Furl Google

Hugg Jamespot Jeqq Kaboodle kirtsy linkaGoGo LinksMarker Ma.gnolia Mister Wong Mixx MySpace MyWeb Netvouz

Newsvine oneview OnlyWire PlugIM Propeller Reddit Rojo Segnalo Shoutwire Simpy Slashdot Sphere Sphinn

Spurl Squidoo StumbleUpon Technorati ThisNext Twitter Webride Windows Live Worlds Movies Yahoo!

Email This to a Friend

Copy HTML: 

 If you like this then please subscribe to the RSS Feed.

Powered by Bookmarkify™

More »