Wednesday, 21 November 2018
The road to Infinispan 10 (Alpha1)
Today we are releasing 10.0.0.Alpha1 and 9.4.2.Final.
Infinispan 9.4.2.Final comes with a number of bug fixes and some small additional features:
We have begun working on what will become Infinispan 10. As with all new major releases, this will come with a number of important changes.
New Server We are working on a new lightweight server, currently dubbed ServerNG, which will supersede the current WildFly-based offering. The new server will have a smaller disk and memory footprint, a new RESTful admin interface, improved security. It will still use familiar components (Elytron for security, Narayana for transactions, etc) but we hope that the installation and usability experience will be most improved. A dedicated blog post will describe in detail what is coming.
Long-term Storage Format The persistent storage format will be changed so that it will be easier to transparently make changes to it without requiring further exporters/importers.
Non-blocking listeners The listener implementation will be replaced with a non-blocking implementation.
Asynchronous CacheLoader/Store Store operations will be ran in another thread to provide non blocking for main threads
Improved statistics Infinispan statistics have been traditionally over-simplistic, offering mostly basic averages for writes and reads. We are going to implement percentiles on a histogram as well as recording tracing information so that you will be able to know how much time is being spent in the various subsystems (clustering, persistence, etc.)
New API The current Infinispan API, based around Java’s ConcurrentHashMap design, does not offer the flexibility required to support modern reactive designs as well as the various extensions we’ve added over the years (counters, multimaps, etc). We are therefore working on a new modern API design which we will be describing with a number of blog posts in the near future.
Agroal JDBC Connection Pool We are replacing the JDBC connection pool implementation with Agroal.
Kubernetes Operators Operators are all the rage in the Kubernetes world, and we are working on an Infinispan Operator which will take care of managing and monitoring the health of an Infinispan cluster, handle scale up/scale down safely, perform upgrades and more.
Infinispan 10.0.0.Alpha1 is the first release from our development branch. It currently includes the following features on top of what is in 9.4.2.Final:
Please report any issues in our issue tracker and join the conversation in our Zulip Chat to shape up our next release.
Tags: release final alpha roadmap
Tuesday, 19 July 2011
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!