Infinispan 10.x servers have some significant changes to marshalling that impact Spring Boot users.

The default Marshaller for Infinispan 10.x is ProtoStream, which uses Protocol Buffers to provide extensible, language and platform neutral serialization.

Unfortunately ProtoStream does not currently work with Infinispan Spring Cache and Session support. As a result, Spring users in Remote Client/Server Mode must use the Java Serialization Marshaller and add classes to a Java serialization whitelist.

Add the following configuration properties:

infinispan.remote.marshaller=org.infinispan.commons.marshall.JavaSerializationMarshaller infinispan.remote.java-serial-whitelist=org.infinispan.tutorial.simple.spring.remote.*

The infinispan.remote.java-serial-whitelist property specifies the classes, or packages, that Java serialization can marshall. Separate multiple class names with a comma (,).

Note that, in previous versions, JBoss Marshaller was the default for Infinispan. Spring users can also use JBoss Marshalling, but it is deprecated as of Infinispan 10.x.

You can find these releases in the maven central repository.

Please report any issues in our issue tracker and join the conversation in our Zulip Chat to shape up our next release.

Enjoy,

The Infinispan Team

From the Infinispan documentation: Hot Rod client can keep a local cache that stores recently used data. Enabling near caching can significantly improve the performance of read operations get and getVersioned since data can potentially be located locally within the Hot Rod client instead of having to go remote.

Near caching can improve the performance of an application when most of the accesses to a given cache are read-only and the accessed dataset is relatively small. When an application is doing lots of writes to a cache, invalidations, evictions and updates to the near cache need to happen. In this scenario we won’t probably get much benefit.

As I said in the introduction, the good news is that this feature can be activated just by configuration. Code doesn’t change, so we can measure the benefits, if such exist, in a very straightforward way.

I have created a very simple application, available here. Maven, Java 8 and an Infinispan server are required to run it. You can download the server or use docker.

Docker: docker run -it -p 11222:11222 jboss/infinispan-server:9.4.0.Final

Standalone: PATH/infinispan-server-9.4.0.Final/bin/standalone.sh

Once the server is up and running, build the application using maven 

>> infinispan-near-cache: mvn clean install

I need to configure two properties:

The hotrod client configuration is for each client, not for each cache (this might change in the future). With that in mind, note that configuring the previous properties will activate near caching for all the caches. If you need to activate it just for some of them, add the following property:

Configuration can be placed in the hotrod-client.properties, Spring-boot configuration or code.

My dataset contains 25 contributors. If I activate the near cache with max 12 entries and I run my reader again, I get the job done in ~1900 milliseconds, which is already an improvement. If I configure it to hold the complete dataset, I get it done in ~220 milliseconds, which is a big one!

When you use Infinispan, you rely on some, very specific version. The same applies to Spring. Before Infinispan 9 our integration modules had a compile-time dependency to a very specific version of Spring. In practice, we imposed this specific version to each project which used our integration bits. The question is - what to do to use some other version of Spring or Spring Boot? Till Infinispan 9, the simplest solution was to exclude Spring from infinispan-spring4-embedded (or infinispan-spring4-remote) artifact using Maven exclusions. Not a very nice and intuitive solution was it?

You probably noticed, when you use JPA you don’t care about underlying implementation. Is it Hibernate, OpenJPA…​ it doesn’t matter?

If you think carefully about Spring for a while, it’s a bit similar. All core classes might be delivered using standard dependency mechanism (adding spring-beans, spring-context manually), using Spring Boot (adding spring-boot-starter) or even using 3rd party integration tools like DropWizard. In case of a bigger project, a decision whether or not use any of those solutions needs to be taken long before Infinispan is chosen as a Distributed Store or Cache.

At this point, we can do a mental experiment - treat Spring classes as a Spec or API and those delivery mechanisms treat as implementations.

===

===

===