Infinispan 11.0.0.Final

Cross-site replication is one of our most used features, as it enables a number of very useful use-cases such as geographical load distribution, zero-downtime disaster recovery and follow-the-sun data centers.

In this release we completely overhauled the way we implement asynchronous cross-site replication by introducing conflict resolution, based on vector clocks, as well as multiple site masters to increase throughput and reliability. This means that you can have multiple active sites safely replicating data between each other.

Infinispan Server’s security, while very powerful, was also tricky to set up because of the configuration complexity. Since we wanted to make the server secure by default, we put a lot of work in simplifying the configuration and removing all of the boilerplate. Additionally, if you are securing the server with Keycloak, accessing the console will correctly obtain credentials through the realm login page.

Our quest to make better use of the available hardware resources in all deployment models (bare-metal, containerized, virtualized) continues as we’ve now consolidated a lot of thread-pools into just two: non-blocking and blocking. Most of the code now makes use of the non-blocking pool. Paths which may block, such as certain persistent stores, use the blocking pool so that they don’t hold up work that may be processed without blocking. This release also includes a new non-blocking Store SPI, so that you can take advantage of stores with real non-blocking I/O.

As Infinispan is participating in CloudButton, a Serverless Data Analytics Platform which is part of the European Union’s Horizon 2020 research and innovation programme, we have introduced a new optional feature which allows scaling by adding new nodes to a cluster without state-transfer. This means that you can add capacity with zero-impact to your operations. Obviously this comes at the cost of reduced resilience in case of failures, but, for scenarios where high availability is not required, this gives you a highly scalable in-memory storage solution.

If high availability is your thing, the rebalancing algorithm which decides how segments (our subdivision of the data space) are mapped to nodes has been overhauled to be much more accurate and fairer.

Querying and indexing will be the major focus in Infinispan 12 (with the long awaited upgrade to Hibernate Search 6 and Lucene 8). In preparation for that, a lot of work has gone into deprecations, usability, clean ups and documentation.

Many usability changes have been added to our Java Hot Rod client:

If you are using the JDBC cache store to persist your cache entries to a database, Infinispan Server now restores the ability to create shared datasources which was lost when we abandoned the WildFly base.

The CLI received a number of new features such as logging manipulation, obtaining sever reports and user management, superseding the user-tool script.

Our console overhaul, which started in 10, continues with lots of new features, integrations and polishing. Highlights are:

Our Infinispan Server image is now based on ubi-minimal:8.2.

And thanks to our friends over at Quarkus, Infinispan Server is now also available as a native image built using GraalVM. This image is available on Quay.io and Docker Hub.

The Kubernetes Operator adds a new Cache Custom Resource and the ability to expose services via Ingress and Routes.

Documentation has also received a lot of love in all areas: