Main Content

Infinispan is an extremely scalable, highly available data grid platform - 100% open source, and written in Java.  The purpose of Infinispan is to expose a data structure that is highly concurrent, designed ground-up to make the most of modern multi-processor/multi-core architectures while at the same time providing distributed cache capabilities.  At its core Infinispan exposes a Cache interface which extends java.util.Map.  It is also optionally is backed by a peer-to-peer network architecture to distribute state efficiently around a data grid.

Offering high availability via making replicas of state across a network as well as optionally persisting state to configurable cache stores, Infinispan offers enterprise features such as efficient eviction algorithms to control memory usage as well as JTA compatibility.

In addition to the peer-to-peer architecture of Infinispan, on the roadmap is the ability to run farms of Infinispan instances as servers and connecting to them using a plethora of clients - both written in Java as well as other popular platforms.

Why is Infinispan sexy?

State-of-the-art core - Infinispan's core is a specialised data structure, tuned to and geared for a great degree of concurrency - especially on multi-CPU/multi-core architectures. Most of the internals are essentially lock- and synchronization-free, favouring state-of-the-art non-blocking algorithms and techniques wherever possible.  Even though non-clustered caching (LOCAL mode) is not its primary goal, Infinispan still is very competitive here.

Massive heap - If you have 100 blade servers, and each node has 2GB of space to dedicate to a replicated cache, you end up with 2 GB of total data. Every server is just a copy. On the other hand, with a distributed grid - assuming you want 1 copy per data item - you get a 100 GB memory backed virtual heap that is efficiently accessible from anywhere in the grid. Session affinity is not required, so you don't need fancy load balancing policies. Of course you can still use them for further optimisation. If a server fails, the grid simply creates new copies of the lost data, and puts them on other servers. This means that applications looking for ultimate performance are no longer forced to delegate the majority of their data lookups to a large single database server - that massive bottleneck that exists in over 80% of enterprise applications!

Extreme scalability - Since data is evenly distributed, there is essentially no major limit to the size of the grid, except group communication on the network - which is minimised to just discovery of new nodes. All data access patterns use peer-to-peer communication where nodes directly speak to each other, which scales very well.

Not Just for Java (PHP, Python, Ruby, C, etc.) - The roadmap has a plan for a language-independent server module. This will support both the popular memcached protocol - with existing clients for almost every popular programming language - as well as an optimised Infinispan-specific protocol. This means that Infinispan is not just useful to Java. Any major website or application that wants to take advantage of a fast data grid will be able to do so.

Support for Compute Grids - Also on the roadmap is the ability to pass a Runnable around the grid. You will be able to push complex processing towards the server where data is local, and pull back results using a Future. This map/reduce style paradigm is common in applications where a large amount of data is needed to compute relatively small results.

Management is key! - When you start thinking about running a grid on several hundred servers, management is no longer an extra, it becomes a necessity. This is on Infinispan's roadmap. We aim to provide rich tooling in this area, with many integration opportunities.

Infinispan and JSR 107

JSR 107, Temporary Caching for Java, is a standard that the Infinispan development team actively participate in.  While Infinispan doesn't currently implement JSR 107 in its current incarnation, work is underway to achieve JSR 107 compliance once the JSR completes.

Recent blog posts

Manik's take on JUDCon India
Jan 26, 2012 10:31 AM by Manik Surtani
JUDCon has, for the first time ever, spread beyond the western world. JUDCon India, held on Tuesday and Wednesday this week, was a roaring success with over 800 passionate community members flocking to the event held in Bangalore, India's answer to C…
JUDCon India post-mortem
Jan 25, 2012 2:40 PM by Galder Zamarreño
JUDCon India is finished now and I was hugely impressed with what I saw in the conference. First of all, it was by far the biggest crowd I've seen in a JUDCon event so that's excellent news. The more, the merrier :) The attendants have been excelle…
Infinispan 5.1.0.FINAL is finally here!!
Jan 24, 2012 1:06 PM by Galder Zamarreño
After over 4 months of development, testing, profiling...etc, I'm extremely pleased to announce that Infinispan 5.1.0.FINAL 'Brahma' is out now! It comes with some very important brand new features such as:Optimistic vs pessimistic locking separation…
Infinispan coming to India!!!
Jan 19, 2012 11:33 AM by Galder Zamarreño
Next week Manik and I will be representing the Infinispan contingent at JUDCon India in Bangalore and we have plenty to talk about: Tuesday, 24th January Infinispan: The Path Ahead - Manik Extreme Performance and Scalability with Infinispan Near …
Infinispan 5.1.0.CR4 is out!
Jan 17, 2012 6:19 AM by Galder Zamarreño
Over the past week we've been busy profiling Infinispan, in particular we've been trying to maximise the performance of Infinispan transactional caches which received a major overhaul int the 5.1 'Brahma' series, and the result is that instead of goi…
View more recent blog posts

Recently Resolved Issues

  ISPN-1779: IllegalArgumentException on TimSort
  ISPN-1806: Potential race condition results in StateTransferInProgressException on view change
  ISPN-1784: Reduce thread notifications in CommandAwareRpcDispatcher.FutureCollator
  ISPN-1787: MurmurHash3 performance optimizations
  ISPN-1793: Have ComponentRegistry expose getters for commonly retrieved components at runtime
  ISPN-1795: GenericTransactionManagerLookup should attempt to use an embedded JBossTM instance if JNDI lookups fail, before falling back to a DummyTM
  ISPN-1792: API to return modification timestamp of a given entry

         

Desktop wallpaper | Project Swag