Friday, 19 January 2018

First candidate release for Infinispan 9.2.0 is out!

Infinispan 9.2.0.CR1 is out! The Infinispan team took time off over the festive period but in spite of that we managed to pack in quite a bit as we approach Infinispan 9.2.0 final release.

Here are the highlights:

  • Remove listener in embedded only fired when something is actually removed - ISPN-8585.
  • CacheNotFoundException ERROR message in server was deemed too noisy, so it was changed to DEBUG message. If RemoteCacheManager.getCache() returns null, the cache does not exist - ISPN-8579.
  • Infinispan is now compatible with JCache 1.1 - ISPN-8571.
  • Hibernate 5.2 compatible Infinispan cache provider (on top of Hibernate 5.1 compatible provider) - ISPN-8570.
  • Documentation added on how to use Hibernate 5.2 and 5.1 Infinispan cache providers shipped with Infinispan 9.2.
Full details of the new features and enhancements included in this release can be found here.
Thank you for following us and stay tuned!


Easier Infinispan clusters on same JVM with Infinispan 9.2

Since Infinispan 5.2.0, Infinispan registers JMX MBeans by default even if statistics are disabled. This was done so that management related operations could be called even if statistics were disabled.

This change resulted in a small usability problem for those users that wanted to create a cluster of Infinispan instances on the same JVM. This is a very common use case when first starting to use Infinispan or when trying to create some unit tests.

When multiple Infinispan instances run on same JVM, they would all try to register JMX MBeans but unless you explicitly gave each Infinispan instance a different CacheManager name, you'd see exceptions like this:

Caused by: org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=Cache,name="___defaultcache(repl_sync)",manager="DefaultCacheManager" already registered under 'org.infinispan' JMX domain...

Starting with Infinispan 9.2.0, duplicate JMX domains are allowed by default, so you won't need to fiddle with JMX domain settings any more to create an Infinispan cluster on the same JVM :)


Monday, 8 January 2018

Improving collect() for distributed Java Streams in Infinispan 9.2

As we progress with the release of Infinispan 9.2 pre-releases, it's important to highlight some of the more interesting improvements from an end-user perspective.

As mentioned before, Infinispan Distributed Java Streams can be used to calculate analytics over existing data. Through overloading of methods, Infinispan is able to offer a simple way of passing lambdas that are made to be Serializable without the need of explicit casting. Being able to produce binary formats for the lambdas is an important step for java streams executions to be distributed. In this example, the cached values are being filtered to find those that have a delay bigger than 0. This lambda can be safely distributed without the need to cast to Serializable because values().stream() returns org.infinispan.CacheStream that overloads filter to take a SerializablePredicate:

Cache<String, Stop> cache = ...
  .filter(e -> e.delayMin > 0);

However, there was one area which was still a bit clunky to use: Java Collectors. When Java Streams came out, the JDK provided a class called which includes a lot of helper methods for collecting results after stream processing. The problem with the Collector instances returned by the helper methods is that they're not Serializable.

Before Infinispan 9.2, we worked around this problem with the help of which defined a serializableCollector method that took a SerializableSupplier<Collector<T, ?, R>>. The aim here was this: even if the Collector instance is not Serializable, the function that creates the Collector can be made to be Serializable. It could be used this way:

Cache<String, Stop> cache = ...
  CacheCollectors.serializableCollector(() -> Collectors.groupingBy(
      e -> getHourOfDay(e.departureTs),

Although this worked, it was a clunky, so in Infinispan 9.2 we overloaded collect() in org.infinispan.CacheStream to take SerializableSupplier<Collector<T, ?, R>>. This means that in Infinispan 9.2, the code above can be written like this instead:

Cache<String, Stop> cache = ...
  () -> Collectors.groupingBy(
      e -> getHourOfDay(e.departureTs),

This is a cleaner way of making sure Collector instances returned by can be distributed.


Thursday, 21 December 2017

2017: A busy year for Infinispan evangelisation!

It's been a very busy year from an Infinispan evangelisation perspective, so before the year ends, we wanted to round up the conferences and user groups that featured Infinispan related talks. This is a good opportunity to catch up on what we've been showing in our Infinispan outings:

Patterns d’utilisation de systèmes in memory 

by Emmanuel Bernard and Galder Zamarreño
@ Devoxx France

This was our first outing of the year with Emmanuel and I showing the audience at Devoxx France the different use cases for data grids. This was also the first time we showed swiss train related demos which we'd improve throughout the year. Slides can be found here and video below:

Big Data In Action with Infinispan

by Galder Zamarreño
@ Great Indian Developer Summit
@ Berlin Buzzwords
@ Red Hat DevNation Live

In this talk, I focused on the big data related use cases for Infinispan. I showed how Infinispan could be used for near real-time data processing using Continuous Querys, and how to analise data using distributed Java Streams. Slides can be found here and the demo here. The video from the DevNation talk can be found here:

HACEP: Highly available and horizontally scalable complex event processing

by Ugo Landini, Sanne Grinovero, Andrea Leoncini, Andrea Tarocchi
@ Red Hat Summit

In this hands on lab, Ugo et al showed how to build a highly available and scalable complex event processing engine with Red Hat JBoss BRMS and and Red Hat JBoss Data Grid (the commercial supported version of Infinispan). This workshop resulted in unmissable architecture reference guide.

Learn how to build Functional Reactive Applications with Elm, Node.js and Infinispan

by Galder Zamarreño
@ Great Indian Developer Summit
@ J On The Beach

The aim of this talk is to demonstrate how Infinispan's Node.js client could be combined with Elm and Infinispan server instances to build a functional reactive application. The talk focused on how build a CRUD application using Elm and Node.js technologies and using Infinispan in-memory data grids for storing and querying information. Slides can be found here:

Streaming Data Analysis with Kubernetes

by Galder Zamarreño

This talk is a spin off of the big data in action talk which focuses on exploring in greater detail how streaming data can be analysed within a Kubernetes orchestrated cluster. The demo can be found here and the slides here:

Data grids : descubre qué esconden los datos

by Galder Zamarreño

This talk is a Spanish spin off the analytics part of the big data in action talk. Not only did it showed how to use distributed Java Streams to analyse data with Infinispan, but also demonstrated the capabilities of Spark/Hadoop integrations. The demos can be found here and here, and the slides here:

Streaming Data : ni pierdas el tren, ni esperes en balde

by Galder Zamarreño

A Spanish version of the streaming data analysis talk delivered in Basel One. This talk was recorded, so hoping for the video to be available soon. In the mean time, the demo can be found here and the slides here:

Streaming Data Workshop

by Katia Aresti, Thomas Segismont and Galder Zamarreño

A hands-on workshop showing how to work with streaming data with Infinispan and Vert.x, on top of OpenShift container platform. No videos were recorded but you can follow this workshop step by step following instructions here. The Github repository can be found here and the latest slides here:

There's plenty the to keep you entertained between now and the new year! :)

If you have any doubts about the talks above, or you encounter any issues running the demos, do not hesitate contacting us! In the mean time, the Infinispan team is working hard on Infinispan 9.2 as well as improving our OpenShift integration.


Tuesday, 19 December 2017

Infinispan 9.1.4.Final Released

Dear Infinispan Community,

We're excited to announce the release of Infinispan 9.1.4.Final, which can be found on our download page.

Full details of the various fixes included in this release can be found here.

Monday, 18 December 2017

Infinispan 9.2.0.Beta2 Released

Dear Infinispan Community,

We're excited to announce the release of Infinispan 9.2.0.Beta2, which can be found on our download page.

The highlights of 9.2.0.Beta2 are:

  • MultiMaps are now available over hotrod [ISPN-7887].
  • Clustered Counters are now available in the server and can be managed via the management api [SPN-8376] or the web console [ISPN-7927].
  • Biased reads in scattered cache [ISPN-8458].
  • Conflict resolution on partition merges are now implemented for DENY_READ_WRITES and ALLOW_READS strategies [ISPN-8440].

Full details of the new features and enhancements included in this release can be found here.
Thank you for following us and stay tuned!

The Infinispan Team

Thursday, 14 December 2017

First steps with Vert.x and Infinispan - PUSH API (Part 2)

Welcome to the second in a multi-part series of blog posts about creating Eclipse Vert.x applications with Infinispan. In the previous blog post we have seen how to create a REST API. The purpose of this tutorial is to showcase how to create a PUSH API implemented with Vert.x and using Infinispan as a server.
All the code of this tutorial is available in this GitHub repository. The backend is a Java project using Maven, so all the needed dependencies can be found in the pom.xml. The front is a super simple react application.


Creating a REST API is very straightforward. But today, even if we are heavily using REST, we don't always want to use request/response or polling, but instead we want to push directly from the server to the client. In this example, we are going to create an API that pushes every new value inserted in the default cache of Infinispan. These values are cute names, as we did in the REST API example.

We are using two features here :
  • Infinispan client listeners
  • Vert.x bridge between the Event Bus and the browser
Infinispan Listeners provide a way to the client get notified when something happens in a cache.

The Event Bus Bridge that connects to the browser, uses SockJS. SockJS is a JavaScript library that provides a WebSocket API, but it can be used with browsers that don't support web-sockets (see the website of the project for more detailed information). Vert.x supports this library and creates a bridge between your browser and your back-end easily through the Event Bus.

Creating an Event Bus bridge

Vert.x is a reactive framework, which means that uses RxJava too, and provides a fancy API on top of it.

First, we are going to create a new verticle called SendCuteNamesAPI. This verticle extends the CacheAccessVerticle we created in the previous blog postCacheAccessVerticle initialises the connection with Infinispan using the Hot Rod protocol.

Now we need to create a SocketJSHandler. This handler has a method called bridge, where we configure some BridgeOptions. Obviously we don't want the client to be able to read everything traveling on the event bus, and this won't happen. We configure an address, 'cute-names', and we add the permission to read and write to this address.

This handler is passed to the event bus route, where the path is /eventbus/*.

Finally, we create a http server as we did in the REST API example. The difference is that instead of calling listen method, we call rxListen and subscribe.

Getting notified and publishing

Using Infinispan listeners is very easy.

First, we are going to create a class that has the @ClientListener annotation. The client listener has to be added to the cache client configuration. We add a protected method called addConfigToCache that will be called just after the initialisation of the defaultCache in the abstract CacheAccessVerticle. Verticles extending the abstract class can now add custom configuration to the client.

We want to be notified when a new entry is created. In this case, our listener has to contain a method with the @ClientCacheEntryCreated annotation on it. The signature of the method has to include a ClientCacheEntryCreatedEvent<String> parameter. This parameter will hold the 'key' of the entry that has been created.

Finally, we use the key to retrieve the name using the getAsync method and then publish the value in the Vert.x event bus to the address where the socket listener is permitted to readcute-names.

Now we can run the main method and whenever we post a new name, we will see in the logs that the client listener is notified!

Client code

We are going to create a super simple react application that will just display hello. React community is *huge*, so there are lot's of tutorials out there to create a hello world client application. This application has a single component that displays "Hello".

The react application runs calling npm install and npm start  in http://localhost:9000/.

Now we need to connect the client to the backend with SockJS. Vert.x provides a JavaScript library for that: vertx3-eventbus-client, built on top of SockJS. We create an EventBus object that will connect to http://localhost:8082/eventbus as we configured in the SendCuteNamesAPI. We register a handler on the 'cute-names' address. The body of the message will contain the new cute name published in the event bus. Every time the handler is called, we update the component's state, and it will be rendered.

Wrap up

We have learned how to create PUSH APIs with Vert.x, powered by Infinispan. The repository has some unit tests. Feedback is more than welcome to improve the code and the provided examples. I hope you enjoyed this tutorial ! On the next tutorials we will talk about Infinispan as the cluster manager for Vert.x. Stay tuned !