Monday, 22 January 2018

Infinispan coming to Snowcamp 2018

This week, the 25th of January, I will be presenting a talk about Clustered Locks at the Snowcamp 2018 conference in Grenoble (France). During the live-coding talk, I will share the design and code I've been working on to create this first version of the clustered locks. These locks will be used by the Vert.x Cluster Manager, but they can be useful to any Infinispan user since version 9.2 (final release coming very soon!!). If you are planning to use this API, we would love to hear from you to give us some feedback and keep us posted on your use case!

If you are attending the conference, fell free to reach me to discuss about Infinispan+Vert.x, locks, Multimap, cute names or any other topic that you care about!

See you!


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.