Infinispan 5.0.1.FINAL is out!

Thanks to everyone that downloaded Infinispan 5.0.0.FINAL in the last month. We've had tremendous feedback and as a result of that we've just released Infinispan 5.0.1.FINAL to address some of the most important issues reported. These issues are primarily around distribution clustering mode and rehashing. So, if you're using any of these features, I'd strongly recommend that you upgrade as soon as possible.

Please keep the feedback coming, and as always, you can download the release from here and you get further details on the issues addressed in the changelog.

Finally, we know have a documentation space fully dedicated to Infinispan 5.0. Make sure you check it out!

Cheers,
Galder

JavaOne 2011 and Devoxx 2011

I never got around to blogging about this when my talks were accepted for JavaOne this year, but it's about time.

I have a conference session titled "A Tale About Caching (JSR 107) and Data Grids (JSR 347) in Enterprise Java" and a BoF session focused on JSR 347 titled "Making Java EE Cloud-Friendly: JSR 347, Data Grids for the Java Platform", which I will be delivering with fellow Infinispan developer, JBoss rockstar and overall nice guy Pete Muir.

Later on in the year, I will also be running a University talk at Devoxx in Antwerp, titled "A real-world deep-dive into Infinispan".  This too will be with Pete and Mircea Markus, another core Infinispan developer.

This will be a great chance to learn more about Infinispan, data grids, JSR 107 and JSR 347, so if you are attending these conferences, make sure you add these talks to your agenda!  :-)

Cheers
Manik

Transactions enhancements in 5.0

Besides other cool features such as Map reduce and distributed executors, Infinispan 5.0.0 "Pagoa" brings some significant improvements around transactional functionality:

• transaction recovery is now supported, with a set of tools that allow state reconciliation in case the transaction fails during 2nd phase of 2PC. This is especially useful in the case of transactions spreading over Infinispan and another resource manager, e.g. a database (distributed transactions). You can find out more on how to enable and use transaction recovery here.
• Synchronization enlistment is another important feature in this release. This allows Infinispan to enlist in a transaction as an Synchronization rather than an XAResource.This enlistment allows the TransactionManager to optimize 2PC with a 1PC where only one other resource is enlisted with that transaction (last resource commit optimization). This is particularly important when using Infinispan as a 2nd level cache in Hibernate. You can read more about this feature here.
• besides that several bugs were fixed particularly when it comes to the integration with a transaction manager - BIG thanks to the community for reporting and testing them!

To summarise, Infinispan can participate in a transaction in 3 ways:

1. as a fully fledged XAResource that supports recovery
2. as an XAResource, but without recovery. This is the default configuration
3. and as an Synchronization

In order to analyze the performance of running Infinispan in different transactional modes I've enhanced and used Radargun. The diagram below shows a performance comparison between running Infinispan in all the 3 modes described. The forth plot in the chart shows the performance of running Infinispan without transactions - this gives an idea about the cost of using transactions vs. raw operations.

The benchmark was run on this Radargun configuration, using Infinispan 5.0.0.CR5 configured as shown here. As a TransactionManager JBossTS 4.15.0.FINAL was used, configured with a VolatileStore as shown here. Each node was an 4-core Intel(R) Xeon(R) CPU E5640 @ 2.67GHz, with 4GB RAM.

Each transaction spread over only one put operation. The chart shows the following:

• a non-transactional put is about 40% faster than a transactional one
• Synchronization-enlisted transactions outperform an XAResource enlisted one by about 20%
• A recoverable cache has about the same performance as a non-recoverable cache when it comes to transactions.

And that's not all! During Infinispan 5.0.0 development we've been thinking a lot about how we can improve transactional throughput, especially in scenarios in which multiple transactions are writing on the same key. As a result we've come up with some improvement suggestions summarised here: please feel free to take a look and comment!

Cheers,

Mircea

Infinispan 5.0.0.FINAL has hit the streets!

So here we have it - Infinispan 5.0 Pagoa has been released.  This is a big, big release over 4.2.x, with over 45 new features (including the much more robust PUSH-based rehashing, XA recovery, smart L1 invalidation and virtual nodes) and over 30 bugs squashed, including several critical performance and stability related ones.  Major new programming models are supported too - from Spring and CDI through to OSGi, map/reduce and distributed code execution.

Pagoa has gone through over six months of development, the first alpha being made publicly available in December 2010, and 8 whole release candidates since the end of April this year.  This is the most stable, fastest, feature-rich version of Infinispan to date.  Pagoa has been integrated in other products, projects, frameworks and services - including the lightning-fast JBoss AS 7 - and we expect to see much, much more in this regard.

Pagoa really is a community-centric release.  I've seen loads of participation, from users, system integrators, extension-authors, researchers and academics, framework authors, and PaaS providers.  This participation has taken the form of providing feedback and bug reports through to profiler analysis; from helping with documentation and demos through to contributing major new features; from suggesting ideas and improvements to participating in detailed design meetings.  It is this participation that really helps Infinispan grow and mature, and at the same time innovate, taking us one step closer to becoming the best damn data grid out there.

So, a big thank you to everyone who participated, this really is your release.

As usual, download the release, provide feedback, read through the detailed changelog.  And check out our brand-new documentation site too!!  :-)

Finally, in other news, I recently blogged about Brahma, the codename for Infinispan 5.1. Yes, work has already started here, expect Brahma to be a real firecracker.  Check out the post, vote for your most desired features.  Brahma will also form the basis of Red Hat's Enterprise Data Grid product, which was announced in May.  You'll finally have a fully supported open source data grid!

Enjoy!

Manik

Infinispan in JBoss AS7

A couple weeks ago saw the final release of JBoss AS 7.0. Like AS6 before it, AS7 uses Infinispan as the distributed caching solution behind its clustering functionality. So what do you need to know about using Infinispan in AS7?

Configuration

Unlike previous releases of JBoss AS, AS7 centralizes all server configuration into one location. This include Infinispan cache configurations, which are defined by the Infinispan subsystem, within domain.xml or standalone.xml:

$JBOSS_HOME/domain/configuration/domain.xml

$JBOSS_HOME/standalone/configuration/standalone-ha.xml

The complete schema for the Infinispan subsystem is included in the AS7 binary distribution:

$JBOSS_HOME/docs/schema/jboss-infinispan.xsd

If you are familiar with Infinispan's native configuration file format or the corresponding configuration file from AS6, you'll notice some obvious similarities, but some noteworthy differences.

While a native Infinispan configuration file contains cache configurations for a single cache container, like AS6, the Infinispan subsystem configuration defines multiple cache containers, each identified by a name. As with AS6, cache containers can have 1 or more aliases.

Being concise

The Infinispan subsystem's configuration schema attempts to be more concise than the equivalent configuration in AS6. This is a direct result of the following changes:

Where is <global/>?

Much of the global configuration contains references to other AS services. In AS7, these services are auto-injected behind the scenes. This includes things like thread pools (described below), the JGroups transport (also described below), and the mbean server.

Configuration default values

AS7 supplies a set of custom default values for various configuration properties. These defaults differ depending on the cache mode. The complete set of default values can be found here:

https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src/main/resources/infinispan-defaults.xml

File-based cache store

Because clustering services use the file-based cache store frequently, we've simplified its definition. First, by using a distinctive element, you no longer need to specify the class name. The location of the store is defined by 2 attributes:

<file-store relative-to="..." path="..."/>

The relative-to attribute defines a named path, and defaults to the server's data directory; whereas the path attribute specifies the directory within relative-to, and defaults to the cache container name.

Specifying cache mode

Instead of defining the cache mode via a separate <clustering mode="..."/> attribute, each cache mode uses it's own element, the child elements of which are specific to that cache mode. For example, rehashing properties are only available within the <distributed-cache/> element.

Where is <default/>?

The semantics of the default cache of a cache container are different in AS7 than in native Infinispan. In native Infinispan, the configuration within <default/> defines the cache returned by calls to CacheContainer.getCache(), while <namedCache/> entries inherit the configuration from the default cache.
In AS7, all caches defined in the Infinispan subsystem are named caches. The default-cache attribute identifies which named cache should be returned by calls to CacheContainer.getCache(). This lets you easily modify the default cache of a cache container, without having to worry about rearranging configuration property inheritance.

Specifying a transport

The Infinispan subsystem uses with the JGroups subsystem to provide it's JGroups channel. By default, cache containers use the default-stack as defined by the JGroups subsystem.

<subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">

  <stack name="udp">

    <!-- ... -->

  </stack>

  <stack name="tcp">

    <!-- ... -->

  </stack>

</subsystem>

Changing the default stack for all clustering services is a simple as changing the default-stack attribute defined in the JGroups subsystem. An individual cache-container can opt to use a particular stack by specifying a stack attribute within its transport element.

e.g.

<cache-container name="web" default-cache="repl">

  <transport stack="tcp"/>

  <replicated-cache name="repl" mode="ASYNC" batching="true">

    <locking isolation="REPEATABLE_READ"/>

    <file-store/>

  </replicated-cache>

</cache-container>

JGroups channels are named using the cache container name.

Defining thread pools

Cache containers defined by the Infinispan subsystem can reference thread pools defined by the threading subsystem. Externalizing thread pool in this way has the additional advantage of being able to manage the thread pools via native JBoss AS management mechanisms, and allows you to share thread pools across cache containers.

e.g.

<cache-container name="web" default-cache="repl" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">

  <transport executor="infinispan-transport"/>

<replicated-cache name="repl" mode="ASYNC" batching="true">

    <locking isolation="REPEATABLE_READ"/>

<file-store/>

  </replicated-cache>

</cache-container>

<subsystem xmlns="urn:jboss:domain:threads:1.0">

  <thread-factory name="infinispan-factory" priority="1"/>

  <bounded-queue-thread-pool name="infinispan-transport"/>

    <core-threads count="1"/>

    <queue-length count="100000"/>

    <max-threads count="25"/>

    <thread-factory name="infinispan-factory"/>

  </bounded-queue-thread-pool>

  <bounded-queue-thread-pool name="infinispan-listener"/>

    <core-threads count="1"/>

    <queue-length count="100000"/>

    <max-threads count="1"/>

    <thread-factory name="infinispan-factory"/>

  </bounded-queue-thread-pool>

  <scheduled-thread-pool name="infinispan-eviction"/>

    <max-threads count="1"/>

    <thread-factory name="infinispan-factory"/>

  </scheduled-thread-pool>

  <scheduled-thread-pool name="infinispan-repl-queue"/>

    <max-threads count="1"/>

    <thread-factory name="infinispan-factory"/>

  </scheduled-thread-pool>

</subsystem>

Cache container lifecycle

During AS6 server startup, the CacheContainerRegistry service would create and start all cache containers defined within its infinispan-configs.xml file. Individual caches were started and stopped as needed. Lifecycle control of a cache was the complete responsibility of the application or service that used it.
Instead of a separate CacheContainerRegistry, AS7 uses the generic ServiceRegistry from the jboss-msc project (i.e. JBoss Modular Service Container). When AS7 starts, it creates on-demand services for each cache and cache container defined in the Infinispan subsystem. A service or deployment that needs to use a given cache or cache container simply adds a dependency on the relevant service name. When the service or deployment stops, dependent services are stopped as well, provided they are not still demanded by some other service or deployment. In this way, AS7 handles cache and cache container lifecycle for you.

There may be an occasion where you'd like a cache to start eagerly when the server starts, without requiring a dependency from some service or deployment. This can be achieve by using the start attribute of a cache.

e.g.

<cache-container name="cluster" default-cache="default">

  <alias>ha-partition</alias>

  <replicated-cache name="default" mode="SYNC" batching="true" start="EAGER">

    <locking isolation="REPEATABLE_READ"/>

  </replicated-cache>

</cache-container>

Using an Infinispan cache directly

AS7 adds the ability to inject an Infinispan cache into your application using standard JEE mechanisms. This is perhaps best explained by an example:

@ManagedBean

public class MyBean<K, V> {

  @Resource(lookup="java:jboss/infinispan/my-container-name")

  private org.infinispan.manager.CacheContainer container;

  private org.infinispan.Cache<K, V> cache;

  @PostConstruct

  public void start() {

    this.cache = this.container.getCache();

  }

}

That's it! No JBoss specific classes required - only standard JEE annotations. Pretty neat, no?

There's only one catch - due to the AS's use of modular classloading, Infinispan classes are not available to deployments by default. You need to explicitly tell the AS to import the Infinispan API into your application. This is most easily done by adding the following line to your application's META-INF/MANIFEST.MF:

Dependencies: org.infinispan export

So, how does it all work? If you recall, during server startup, the AS creates and registers an on-demand service for every Infinispan cache container defined in the Infinispan subsystem. For every cache container, the Infinispan subsystem also creates and registers a JNDI binding service that depends on the associated cache container service. When the AS deployer encounters the @Resource(lookup) annotation, it automatically adds a dependency to the application on the JNDI binding service associated with the specified JNDI name. In the case of the Infinispan JNDI binding, the binding itself already depends on the relevant Infinispan cache container service. The net effect is, your application will include a dependency on the requested cache container. Consequently, the cache container will automatically start on deploy, and stop (including all caches) on undeploy.

Sounds great! Where do I get it?

You can download the JBoss AS 7.0.0 Final release here:

http://www.jboss.org/jbossas

User documentation can be found here:

https://docs.jboss.org/author/display/AS7/Documentation

And direct any questions to the user forums:

http://community.jboss.org/en/jbossas/as7_users?view=discussions

Keep a look out for the 7.0.1 release expected in the coming weeks, which contains a number of clustering fixes identified since the initial final release.

How can I contribute?

Here's the best place to start:

http://community.jboss.org/wiki/HackingOnAS7

One last release candidate for Infinispan 5.0

Magic 8, baby!  Let's make this release candidate count.  5.0.0.CR8 is out, download it, provide feedback, we're moving fast towards a final release on Pagoa.

A bunch of bugs fixed over and above CR7, we'd love to hear what you have to say about this release.

Cheers
Manik

Infinispan 5.1 has a codename

The polls are in, and Infinispan 5.1, following tradition of naming releases after quality beers around the world, will be codenamed Brahma, from Brazil.

Beer aside, Brahma is a continuation of the work started with Infinispan 5.0 Pagoa.  Some of the key features of Brahma include:

• Overhaul rehashing and state transfer.  This codebase will be consolidated and significantly improved, starting with the PUSH based rehashing introduced in Pagoa.  Chunking and parallel transfers will also be supported, which will improve the performance and robustness of rehashing/state transfer.
• Improved locking and JTA interactions, including deadlock-minimising reordering and true optimistic and pessimistic modes.
• Versioned entries and an eventually consistent mode and API.  Infinispan has always leaned towards consistency in the CAP triangle at the expense of partition tolerance, in line with most Java Data Grids.  However, we can very easily also support eventual consistency with partition tolerance, and in Brahma we intend to introduce the versioned API to support this.
• Distributed querying based on parallelising a query task across all nodes in the cluster should also make an appearance, an additional query mode to add to the Lucene index-based querying supported in Pagoa.

In addition to these big features, a number of smaller enhancements and improvements are also planned, including:

• Fine-grained AtomicHashMaps.  Anyone using AtomicHashMaps - including Hibernate OGM - will love this!
• Top-level support for JSON documents, including fine-grained replication for deltas in JSON documents.
• Moving off JAXB for configuration parsing, JAXB being too slow and cumbersome to deal with.

So as we come ever closer to releasing Pagoa in its final form, contributors have already started hacking on code for Brahma.  Expect to see alphas of Brahma hit the interwebs very soon!

Enjoy

Manik