Introducing JPA Cache Store

Good news everyone - Infinispan 5.3.0 will be introducing a long awaited JPA cache store.  This cache store will allow you to store cache entries in the database using proper schema - so that other applications can read the persisted data as well.

In normal use cases, it's recommended to leverage Infinispan as JPA second level cache and/or query cache. However, if you'd like to use only Infinispan API and you want Infinispan to read from database, or to persist the data into a database with well defined schema, then JPA cache store could be right for you.

Prior to JPA cache store, those who wants to use Infinispan in front of a database to read/write database records would need to write their own cache store implementation.  Now, with JPA cache store, users can use Infinispan in front of a database (write-through or write-behind) with ease by using standard JPA mapping and configurations.

To use the cache store is simple - create the standard JPA configuration (persistence.xml) and entity class, and then configure the cache store:

Please see documentations for detailed sample usage and configuration.

Hope you enjoy this new addition!

Ray

Infinispan 5.3.0.CR1 is out!

Besides a handful of fixes, this release contains two very important contributions:

• a mongoDB cache store which allows using Infinispan  as a cache on top of a mongodb instance. Courtesy of  Guillaume Scheibel
• a JPA based cache store that allows an easy setup for Infinispan as a cache in front of a database. Courtesy of Ray Tsang

Please stay tuned for blogs detailing these features.

For a complete list of features included in this release refer to the release notes.

Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Mircea

Infinispan to adopt the Apache Software License

Starting with Infinispan 6.0, the project will move from its current GNU Lesser General Public License (LGPL) v.2.1 licence to the Apache License (AL) v.2.0.
The switch from the weak copyleft LGPL license to the more permissive AL one is in response to continued requests from the wider open source community who intend to integrate Infinispan into open source projects that aren’t LGPL-friendly.  A more permissive license broadens Infinispan’s community, ecosystem and general appeal.

To deal with any concerns you may have, I've put together some FAQs below:

Is it still open source?

Yes.  The source code for Infinispan is and always will be open and freely accessible.

Is it as business-friendly?

The AL is often regarded as more business-friendly than LGPL.

How does that affect our existing users?

It doesn't.  You are just as free to use, contribute, and participate in the project.

How does that affect our contributors?

In accordance with the JBoss Contributor License Agreement, all past contributions to Infinispan will be re-licensed to the AL.  Future contributions will be licensed under the AL too.

This relicensing is part of our ongoing effort to build and maintain a strong and inclusive open source community, and I hope you're on our side with this move.

Feel free to post any questions or thoughts as comments on this blog.

Thanks

Manik Surtani

on behalf of the Infinispan team

Interoperability between Embedded and Server Endpoints is here!

As mentioned by Mircea in the Infinispan 5.3.0.Beta2 release blog post, interoperability between embedded Infinispan and remote Infinispan modes, including Hot Rod, Memcached and REST is now here!

What this means is that you should be able to store data via one of the endpoints and retrieve data from a different one. So, I can store an Java object using the Java Hot Rod client, and I can retrieve it using the embedded interface.

Documentation for this new interoperability, or compatibility mode, can be found here, including the key aspects of this new functionality, configuration and links to some examples.

As we head towards the later part of the Infinispan 5.3 series, if you're interested in accessing data in multiple ways, give it a go and let us know what you think!

Cheers,
Galder

Storing arrays in Infinispan 5.3 without wrapper objects!

As we head towards the latter part of Infinispan 5.3 series, we're doing a series of blog posts where we provide more detailed information of some of the key features in this release.

As part of Infinispan 5.3.0.Beta1, we added the ability to store data directly in Infinispan which previously would have required using a custom wrapper object, e.g. arrays. The way Infinispan supports storing these type of objects is by allowing a custom Equivalence function to be configured for keys and/or values.

This is a less cumbersome method that enables object requiring custom equals/hashCode implementations to be stored without incurring on a extra cost per cache entry. We've already been using this internally to store Hot Rod, REST and Memcached data where keys and/or values can be byte arrays, and we've seen some nice improvements in terms of memory consumption.

A nice side effect of being able to store byte arrays natively is that it makes sharing data between multiple endpoints less cumbersome since you're now dealing with byte arrays directly instead of having to wrap/unwrap the byte arrays. More on this topic very shortly.

Full details on how to implement and configure these new Equivalence functions can be found in the Infinispan community documentation. To give this a go, make sure you download the latest Infinispan 5.3 release.

Cheers,
Galder

Infinispan Server: remote protocols improvements

A couple of weeks ago, Infinispan 5.3.0.Beta1 was released, which brought a slew of improvements to two of the remoting protocols: Hot Rod and REST. This week's 5.3.0.Beta2 brings even more goodies: the ability to expose the same container over multiple Hot Rod endpoints and the integration of the WebSocket endpoint. We've also been working on fleshing out the documentation for the server.

Hot Rod SSL

Hot Rod, Infinispan's own high-performance, topology aware protocol, has gained the ability to encrypt the communication using SSL and optionally require client certificate authentication. While this is still not the full-blown authentication/authorization infrastructure we will be implementing for Infinispan 6.0, it is the first step in that direction.
In the context of the Infinispan Server, setting this up is quite simple. Download the Infinispan Server distribution from http://www.jboss.org/infinispan/downloads and unzip it.
Next create a keystore with a self-signed certificate:

$ keytool -genkey -alias hotrod -keyalg RSA -keystore keystore.jks -keysize 2048
Enter keystore password:  secret
Re-enter new password: secret
What is your first and last name?
  [Unknown]:  HotRod
What is the name of your organizational unit?
  [Unknown]:  Infinispan
What is the name of your organization?
  [Unknown]:  JBoss
What is the name of your City or Locality?
  [Unknown]:  Red Hat
What is the name of your State or Province?
  [Unknown]:  World
What is the two-letter country code for this unit?
  [Unknown]:  WW
Is CN=HotRod, OU=Infinispan, O=JBoss, L=Red Hat, ST=World, C=WW correct?
  [no]:  yes

Enter key password for <hotrod>
    (RETURN if same as keystore password):

Put the keystore in the standalone/configuration directory together with the standalone-hotrod-ssl.xml from the docs/examples/configs directory.
Now start the server using bin/standalone.sh -c standalone-hotrod-ssl.xml
This will start a server with a HotRod endpoint on port 11222 which will only accept SSL connections.

Now we need a client:

This client needs to find the keystore.jks file you generated above.

Hot Rod container sharing

Another feature added to the Hot Rod endpoint is the ability to share the same container between multiple endpoints, and exposing them on different interfaces. This could be used to offer an unencrypted backend endpoint to be used by "internal" servers to populate the cache and an encrypted frontend endpoint to be used by "external" applications. With the future addition of authorization, this will offer the ability to handle many types of security scenarios.

REST Extended Headers

The REST endpoint now returns the Expires header for mortal entries. It will also return additional headers when the extended query parameter is added, e.g. GET /cacheName/cacheKey?extended
will return the following custom headers:

• Cluster-Primary-Owner: the node name of the primary owner for this key
• Cluster-Node-Name: the JGroups node name of the server that has handled the request
• Cluster-Physical-Address: the physical JGroups address of the server that has handled the request.

With the introduction of custom metadata, courtesy of ISPN-2281, we will also allow returning that information too.

REST Collections

Another improvement made to the REST endpoint is the ability to retrieve all keys in a cache, by simply invoking a GET /cacheName
This will return a list of keys present in the given cacheName as the body of the response. The format of the response can be controlled via the Accept header as follows:

• application/xml - the list of keys will be returned in XML format.
• application/json - the list of keys will be return in JSON format.
• text/html - the list of keys will be returned in HTML format.
• text/plain - the list of keys will be returned in plain text format, one key per line

If the cache identified by cacheName is distributed, only the keys owned by the node handling the request will be returned. To return all keys, append the "global" parameter to the query, as follows: GET /cacheName?global

WebSocket endpoint

The WebSocket endpoint is now finally part of the new Infinispan Server package. Bear in mind that this is just a pure WebSocket server. When we will be able to upgrade our base from AS 7.x to WildFly 8 we will be able to take advantage of the new Undertow web server which has native support for WebSockets.

Infinispan 5.3.0.Beta2 is out!

The highlights of this release are:

• interoperability between Hot Rod, Memcached, REST and embedded mode. E.g. it is now possible to write data through an REST interface and read it through Hot Rod or the other way around
• the ability to expose the same container over multiple Hot Rod endpoints and the integration of the WebSocket endpoint

Please stay tuned for blogs detailing these features.

For a complete list of features included in this release refer to the release notes.

Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Mircea

Infinispan vs Hazelcast Performance

Sam Smoot has recently compared the performance of Infinispan versus Hazelcast both with default cache settings and posted some interesting performance results with Infinispan coming on top :)

@Sam, we hear you and we're working on reducing the number of JARs required for standalone, default use case :)

Cheers,
Galder

Infinispan 5.3.0.Beta1 is out!

Besides about 30 fixes and several enhancements, Infinispan 5.3.0.Beta1 comes with the following features:

• An preview of the functionality allowing an embedded client to read data written through HotRod and the other way around
• SSL access to Hot Rod
• All the keys in the cluster can now be retrieved over REST
• better internal structures for holding data which should translate in lower memory usage, especially when using infinispan in client/server mode 

Please stay tuned for blogs detailing all these features. For a complete list of features included in this release refer to the release notes.

Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Mircea

The first JUDCon Brazil experience

The first ever JUDCon Brazil was held a couple of weeks back and it was a real blast! Firstly, it offered a great opportunity to meet some members of the JBoss community which have been helping us push JBoss projects forward in this region of the world, such as Hanneli Tavante, Roberto dos Santos Wagner, ...etc. It was great sharing ideas, experiences...etc with them and coming up with new ideas!

As mentioned before in the post before the conference, I had two new presentations to deliver, one on JSR-107 specification on JCache API and Infinispan's implementation, and the other on Hibernate Second Level Cache with Infinispan. The JCache presentation went really well and all the live coding worked as expected.

The second presentation was the busier of the two, with a full room packed with Hibernate/JPA users waiting to hear how to scale up their applications. I got excellent feedback from both presentations and looking forward to giving these presentations in more user groups or conferences.

The presentations are not up yet, but I expect them to be posted online in the next few weeks. In the mean time, here are a couple of temporary links to the PDFs of my presentations:

• Bolttlenecks are out! Java Cache Standard (JSR-107) is in! (PDF)
• Scaling up Hibernate/JPA applications with Infinispan second-level cache (PDF)

The big news of the conference was for sure the announcement of JBoss Application Servers' new name: WildFly. We're actively working with them to make the most out of Infinispan :)

Cheers,
Galder