Infinispan 4.2.1.CR3 is out!

Hi,

This release is a fix for the XSD issue from 4.2.1.CR2. Sorry for the inconvenience caused, we'll make sure that we learn from our mistakes.

Please use the user forums to report back and download the release here.

Cheers,

Mircea

Infinispan Python client beta for Hot Rod servers is here!

The first beta version of the Infinispan native python client to connect to the Infinispan Hot Rod servers is available now from Infinispan's GitHub repository or PyPi. Please check the latest README information to find out more about installation instructions.

So, what's in it? For this first beta release, we've implemented all the operations available in the Hot Rod specification and they've been tested with string inputs. This release does not include code to deal with client intelligence superior to 1, so clients cannot receive notifications of cluster changes nor can they locate data in an intelligent manner by applying consistent hash algorithms to the keys. These capabilities, plus further examples such as how to integrate with payloads from Google Protocol Buffers will come in next beta releases.

If you're looking for code examples for the Infinispan Python client, you can find a very basic one in the README file itself, or check the testsuite within the source package. In next releases we'll be creating a wiki with more detailed examples.

As always, if you have any doubt please use the user forums and for any bugs or feature requests, please log them via JIRA.

Cheers,
Galder

5.0.0.ALPHA3 is here with more goodies!

For those who can't wait to get hold on the newest Infinispan features, we've just released the third alpha release of the 5.0 series, called 5.0.0.ALPHA3.

Apart from including fixes in 4.2.1.CR2, it allows users to prefetch data in advance in parallel thanks to the new getAsync() method. Why is this useful? Imagine the following scenario: A cache is configured with distribution and an app that requires values associated with k1, k2, and k3 in order to do its job. In the worst case scenario assume that all these keys located in remote nodes. Previously, before 5.0.0.ALPHA3, you'd have written something like this:

Value v1 = cache.get("k1");
Value v2 = cache.get("k2");
Value v3 = cache.get("k3");

The problem with this code is that each get() is sequential, so the second get() call must wait for first get() to retrieve data from the remote node before it can execute. This is clearly not very optimal. From 5.0.0.ALPHA3 onwards, you can do this instead:

NotifyingFuture<Value> f1 = cache.getAsync("k1");
NotifyingFuture<Value> f2 = cache.getAsync("k2");
NotifyingFuture<Value> f3 = cache.getAsync("k3");
...
Value v1 = f1.get(); // blocks until value has been returned
Value v2 = f2.get();
Value v3 = f3.get();

The clear advantage here is that the get requests, via getAsync(), can be fired in parallel and they don't need to wait for each other. Afterwards, when the value is needed, simply call get() on the future received.

Amongst other API enhancements, such as RemoteCache implementing size() and isEmpty(), or the ability to delete AtomicMap instances via AtomicMapLookup, it's worth highlighting that we've taken your feedback on board with regards to how Infinispan is configured programmatically, and from 5.0.0.ALPHA3 onwards, we provide a more fluent way of configuring Infinispan. For example:

GlobalConfiguration gc = new GlobalConfiguration();

GlobalJmxStatisticsConfig jmxStatistics = gc.configureGlobalJmxStatistics();
jmxStatistics.allowDuplicateDomains(true).enabled(true);

TransportConfig transport = gc.configureTransport();
transport.clusterName("blah").machineId("id").rackId("rack").strictPeerToPeer(true);

You can find more examples of this new configuration here. Note that this fluent API is likely to evolve further before we go final with 5.0.0 as shown in this forum discussion, but please keep your feedback coming! Finally, details of what's fixed is in the release notes. As always, please use the user forums to report back, grab the release here, enjoy and keep the feedback coming.

Cheers,
Galder

Second release candidate on 4.2.1 is out!

Yes, the much-awaited CR2 of Infinispan 4.2.1, codenamed "Ursus", is finally out.  We've had excellent feedback on 4.2.0 and earlier betas and CRs on 4.2.1, which has led to a large number of bugs fixed and performance improvements implemented.  As always, this is much appreciated, helps make Infinispan a stronger platform for the community, and please do keep this up.  We'd love to hear what you have to say about CR2.

Details of what's fixed is in the release notes.  As always, please use the user forums to report back, grab the release here, enjoy and keep the feedback coming.

Cheers
Manik

JSR-107 and a JSR on data grids

In response to Antonio Goncalves' blog post on his wish list for Java EE 7 and particularly on his comments around the inactive JSR-107 JCACHE spec, I'd like to spend a few moments jotting down my thoughts on the subject.

To start with, I am on the JSR-107 expert group, representing Red Hat.  I have also been in recent discussions with the JCP about the inactive JSR and what can be done about it.

My feel is JSR-107 needs to be axed.  It's been inactive for way too long, it is out of date, and the community is pretty jaded about it.  We do, however, need a JSR around distributed caches and in-memory data grids.  There is definitely a need in the Java EE 7 umbrella specification, particularly with increasing focus and alignment with cloud.  Apps designed to scale would almost certainly need a distributed, in-memory data grid.  If Java EE is to be the preferred platform to build Software-as-a-Service offerings, scalability is crucial.

So what should this data grid JSR look like?  Well, let's start with JSR-107.  After all, I didn't think there was anything wrong with JSR-107, just that it was too limiting/simplistic.

What's in JSR-107?
A quick summary:

• Primary interface - javax.cache.Cache - extending j.u.c.ConcurrentMap
• Adds ability to register, de-register and list event listeners
• Defines a CacheLoader interface for loading/storing cached data
• Defines an evict(K) method, as well as the support for different eviction algorithms
• Defines a ServiceLocator approach to loading the appropriate implementation at runtime
• Defines a CacheManager interface to construct and retrieve Cache instances

What JSR-107 does not cover - but should be included in a Data Grid JSR
Over and above what JSR-107 proposed, I believe the following features are crucial to a useful data grid standard:

• JTA interoperability.  The ability to participate in transactions is necessary, both as an XA resource and as a simple cache to front a RDBMS, via JPA
• Define behaviour at certain stages of a tx's lifecycle, particularly with regards to recovery
• Should play nice with JPA's second level cache SPI
• Define and mandate REPLICATION and DISTRIBUTION, as well as SYNCHRONOUS and ASYNCHRONOUS versions of network communications

These could be useful in the JSR, but needs more thought and discussion

• An asynchronous, Future-based API (See Infinispan's Async API)
• XML-based config file standardisation (including an XSD)
• Standardise programmatic config bean interfaces

Further interesting thoughts

These additional, NoSQL-like features would also be very interesting, but probably more sense in a later revision of this JSR - both for the sake of manageability as well as to allow more community adoption/feedback on such APIs.

• Distributed code execution API
• Map/Reduce API
• Querying/filtering API

I'd like to hear your thoughts and opinions around this - please comment away!

Cheers

Manik