Let’s be honest: it’s pretty exciting that Infinispan now supports Java 8 for many reasons, but perhaps one of the most anticipated reasons is because of the new stream classes. The main reason for this is the fact that it completely transforms the way we process data. Instead of having to iterate upon the data yourself, the underlying stream does this for you, and all you have to do is provide the operations to perform on it. This is perfect for distributed processing because the implementation handles the iteration entirely.
However, another important reason why these kinds of advancements are so important is they make development accessible to younger generations. By creating easier methods, we are actually opening up opportunities for young people to get involved in the tech sector, and creating career paths for people who have earned an information technology degree that feel as though this work may be too hard for them.
On top of this, with the new feature, Distributed Streams, you can perform any operation you normally would on a regular stream on a distributed cache, as long as the operations and data are marshallable. This means, when using a distributed or replicated cache, the keys and values of the cash must be marshallable. The same can be said for intermediate and terminal operations when using these distributed streams.
By introducing lambdas in Java 8, you also don’t have to provide an instance of any new class that is serializable or has an externalizer registered for it, as lambdas can be defined as serializable very easily. Similarly, another awesome addition is the utility class, which allows you to utilize the collectors class normally used with the collect method on stream properly — even when everything has to be marshalled (which normally wouldn’t work for the collectors class).
Another exciting new addition hopes to add on to the already parallel streams of Java 8. A parallel stream allows the operations to be performed in parallel using multiple threads. However, the new parallel distribution function also allows you to run operations simultaneously on different nodes, because data is already partitioned across the nodes anyway. This new feature is available by default, but can also be controlled by using the new CacheStream interface as well and, to be clear, the Java 8 parallel can be used in conjunction with the new parallel distribution likewise.
Below are some of the different methods you can use in the CacheStream interface, and what they do as well (courtesy of Infinispan’s website). These new methods definitely make Infinispan’s stream capabilities incredible, to say the least.
distributedBatchSize
This controls how many elements are brought back at one time for operations that are key aware, such as (spl)iterator and forEach. This is useful to tweak how many keys are held in memory from a remote node. Thus, it is a tradeoff of performance (more keys) versus memory. This defaults to the chunk size as configured by state transfer.
parallelDistribution/ sequentialDistribution
This was discussed in the parallelism section above. Note that all commands have this enabled by default except for spl(iterator) methods.
filterKeys
This method can be used to have the distributed stream only operate on a given set of keys. This is done in a very efficient way, as it will only perform the operation on the node(s) that own the given keys. Using a given set of keys also allows for constant access time from the data container/store, as the cache doesn't have to look at every single entry in the cache.
filterKeySegments
This is useful to do filtering of instances in a more performant way. Normally, you could use the filter intermediate operation, but this method is performed before any of the operations are performed to most efficiently limit the entries that are presented for stream processing. For example, if only a subset of segments is required, it may not have to send a remote request.
segmentCompletionListener
Similar to the previous method, this is related to key segments. This listener allows for the end user to be notified when a segment has been completed for processing. This can be useful if you want to keep track of completion, and if this node goes down, you can rerun the processing with only the unprocessed segments. Currently, this listener is only supported for spl(iterator) methods.
disableRehashAware
By default, all stream operations are what is called rehash aware. That is, if a node joins or leaves the cluster while the operation is in progress, the cluster will be aware of this and ensure that all data is processed properly with no loss (assuming no data was actually lost).
Calling disableRehashAware can disable this; however, if a rehash is to occur in the middle of the operation, it is possible that not all data will be processed. It should be noted that data is not processed multiple times with this disabled — only a loss of data can occur.
This option is not normally recommended unless you have a situation where you can afford to only operate on a subset of data. The tradeoff is that the operation can perform faster, especially (spl)iterator and forEach methods.
With all of this said, it’s safe to say that Infinispan has done a great job of expanding stream capabilities and I can’t wait to see what’s next.
Developers can now get a no-cost Red Hat Enterprise Linux® Developer Suite subscription for development purposes by registering and downloading through developers.redhat.com.
Last updated: February 11, 2024