Thursday, 21 November 2013

Infinispan HotRod C++ Client 6.0.0.Final

When the HotRod protocol was designed, one of the primary goals was to make it language neutral so that applications written in different languages could interact with the data placed inside an Infinispan Data Grid. The HotRod protocol is special because intelligent clients can offer superior performance by being aware of how data is stored in the grid. We offer three levels of client intelligence:
  • L1: simple clients who connect to the grid using a list of statically provided server addresses in round-robin fashion
  • L2: clients are aware of the topology of the grid and can be notified when new servers are added/removed from the grid
  • L3: clients can use the grid topology and the key hashes to directly connect to the node who is the primary owner for a specific item of data, thus reducing the need for remote calls between the server nodes
Until recently, however, we only had three clients:
  • The full-featured Java client (L1, L2, L3)
  • The simple Python client (L1)
  • A C# client developed during the Google Summer of Code by Sunimal Rathnayake (L1)
Today, however, we are proud to announce the 6.0.0.Final release of the HotRod C++ client with support for L1, L2 and L3. This client can be compiled for Linux, Unix and Windows.
I would like to thank SIA, and in particular Lorenzo Filì for all of the great work in getting us to this stage.

In order for the client to achieve feature-parity with the Java client, we still need to add OpenSSL and Remote Query support. We hope to deliver these features during the next development cycle.

So go ahead and download the bits and if you'd like to contribute, head over to our project on GitHub.

Tuesday, 19 November 2013

Infinispan 6.0.0.Final is out!

Dear Infinispan community,


We're pleased to announce the final release of Infinispan 6.0 "Infinium". As announced, this is the first Infinispan stable version to be released under the terms of Apache License v2.0.


This release brings some highly demanded features besides many stability enhancements and bug fixes:


  • Support for remote query. It is now possible for the HotRod clients to query an Infinispan grid using a new expressive query DSL. This querying functionality is built on top of Apache Lucene and Google Protobuf and lays the foundation for storing information and querying an Infinispan server in a language neutral manner. The Java HotRod client has already been enhanced to support this, the soon-to-be announced C++ HotRod client will also contain this functionality (initially for write/read, then full blown querying).
  • C++ HotRod client.  Allows C++ applications to read and write information from an Infinispan server. This is a fully fledged HotRod client that is topology (level 2) and consistent hash aware (level 3) and will be released in the following days. Some features (such as Remote Query and SSL support) will be developed during the next iteration so that it maintains feature parity with its Java counterpart.
  • Better persistence integration. We’ve revisited the entire cache loader API and we’re quite pleased with the result: the new Persistence API brought by Infinispan 6.0 supports parallel iteration of the stored entries, reduces the overall serialization overhead and also is aligned with the JSR-107 specification, which makes implementations more portable.
  • A more efficient FileCacheStore implementation. This file store is built with efficiency in mind: it outperforms the existing file store with up to 2 levels of magnitude. This comes at a cost though, as keys need to be kept  in memory. Thanks to Karsten Blees for contributing this!
  • Support for heterogeneous clusters. Up to this release, every member of the cluster owns an equal share of the cluster’s data. This doesn’t work well if one machine is more powerful than the other cluster participants. This functionality allows specifying the amount of data, compared with the average, held by a particular machine.
  • A new set of usage and performance statistics developed within the scope of the CloudTM project.
  • JCache (JSR-107) implementation upgrade. First released in Infinispan 5.3.0, the standard caching support is now upgraded to version 1.0.0-PFD.


For a complete list of features included in this release please refer to the release notes.
The user documentation for this release has been revamped and migrated to the new website - we think it looks much better and hope you’ll like it too!
This release has spread over a period of 5 months: a sustained effort from the core development team, QE team and our growing community - a BIG thanks to everybody involved! Please visit our downloads section to find the latest release. Also if you have any questions please check our forums, our mailing lists or ping us directly on IRC.


Cheers,
Adrian

Tuesday, 5 November 2013

Infinispan Arquillian Container 1.1.0.Alpha1 released

Dear Infinispan users,
a new version of Infinispan Arquillian Container has been released into JBoss Maven Repository as maven artifacts. The previous version was announced by http://blog.infinispan.org/2012/09/infinispan-arquillian-container-100cr1.html The blog post contains information related to setup of JBoss Maven Repository, including its address as well as address of the Infinispan Arquillian Container itself.

Maybe we should now call the project Infinispan Arquillian extension rather than Infinispan Arquillian Container because, since version 5.3, Infinispan Server has been based on JBoss Application Server 7 and the submodule called infinispan-arquillian-container could be removed.

As a result, the configuration of Arquillian with respect to Infinispan Server was simplified.

Developing tests with Infinispan Server


Now there's only one way to compose the arquillian.xml file:

The property ispnHome no longer exists. The path to the Infinispan Server is now specified via jbossHome. The serverConfig attribute then specifies the correct configuration file for the server.

In order to run tests with Infinispan Arquillian extension, one should use the following dependencies:
org.jboss.as:jboss-as-arquillian-container-managed:jar:7.2.0.Final:test
org.infinispan.arquillian.container:infinispan-arquillian-impl:jar:1.1.0.Alpha1:test

Now that we've configured the server to run in our tests, it's time to introduce a few enhancements which will help you write tests more effectively.

RemoteInfinispanServers

You can still inject the reference to a running Infinispan Server by annotating an instance variable of type RemoteInfinispanServer with @InfinispanResource.

When there are more Infinispan servers to be injected, you can now use the following snippet instead of injecting each server independently:

 
Then you can retrieve individual servers by calling .getServer(name) on the servers variable. The name must correspond to an existing container definition within arquillian.xml. The results of this call will be of type RemoteInfinispanServer.

WithRunningServer

So far users were forced to start the Infinispan Server either before the whole test suite (mode="suite") or before each class separately (mode="class"). The annotation WithRunningServer enables users to automatically start the server before a test method and stop it after the method. Example:

Note that in this case containers should be marked as mode="manual" in arquillian.xml file so that Infinispan Arquillian extension can handle lifecycle of these servers by itself.

When @WithRunningServer annotation is placed on a class, the server(s) will be started before the first method call in the test class, and stopped when JUnit @AfterClass event is triggered.

IPv6 support

Infinispan Arquillian extension can now work with Infinispan Server running on IPv6 as it can correctly connect to the server via JMX.

Testing embedded Infinispan


Running tests with plain Infinispan libraries instead of Infinispan Server has not changed since the last release. Read more about it in the previous blog post.

Thanks to Michal Linhard and Vitalii Chepeliuk who helped move the project one step further.

Cheers,
Martin

Wednesday, 16 October 2013

New book: Performance of Open Source Applications, with a chapter on Infinispan

NOTE: Cross-posted from Manik's personal blog

From the good folks who brought you the excellent Architecture of Open Source Applications (AOSA), available for free online, as a PDF, for e-book readers or as a good old-fashioned dead tree, we're now treated to a new tome - the Performance of Open Source Applications (POSA).

POSA follows the same concept as AOSA - a different authoritative figure in the open source community is responsible for each chapter, providing you with excellent insight on how some of the most popular open source applications have been designed and built.  POSA focuses specifically on performance rather than general software architecture, and I've contributed a chapter on the performance related work conducted for Infinispan (see Chapter 7).

Have a read, I'd love to know what you think.

Cheers
Manik

Tuesday, 8 October 2013

Infinispan 6.0.0.CR1 is available!

Dear Infinispan community,

We are proud to announce the first candidate release for Infinispan 6.0.0.

As many of you would expect from a candidate release this version
contains a multitude of bug fixes/enhancements to get to a stable
6.0.0 release.

For a complete list of features and fixes included in this release
please 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.

Thanks to everyone for their involvement and contributions!

- Will

Friday, 27 September 2013

Infinispan 6.0.0.Beta2 is released!

Dear Infinispan community,

Staying committed to the software development philosophy of "Release early. Release often. And listen to your customers" we are releasing Infinispan 6.0.0.Beta2 today. This is mainly a stabilization release after a flurry of new features released in Beta1. The Beta2 release contains a few fixes related to hotrod remote clients as well as some minor fixes in LevelDB cache store.

For a complete list of features and fixes included in this release please 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,
Vladimir

Thursday, 26 September 2013

Embedded and remote queries in Infinispan 6.0.0.Beta1


If you're following Infinispan's mailing lists you've probably caught a glimpse of the new developments in the Query land: a new DSL, remote querying via Hot Rod client, a new marshaller based on Google's Protobuf. Time to unveil these properly!

The new Query DSL


Starting with version 6.0 Infinispan offers a new (experimental) way of running queries against your cached entities based on a simple filtering DSL. The aim of the new DSL is to simplify the way you write queries and to be agnostic of the underlying query mechanism(s) making it possible to provide alternative query engines in the future besides Lucene and still being able to use the same query language/API. The previous Hibernate Search & Lucene based approach is still in place and will continue to be supported and in fact the new DSL is currently implemented right on top of it. The future will surely bring index-less searching based on map-reduce and possibly other new cool search technologies.

Running DSL-based queries in embedded mode is almost identical to running the existing Lucene-based queries. All you need to do is have infinispan-query-dsl.jar and infinispan-query.jar in your classpath (besides Infinispan and its dependecies), enable indexing for your caches, annotate your POJO cache values and your're ready.


ConfigurationBuilder cfg = new ConfigurationBuilder();
cfg.indexing().enable();

DefaultCacheManager cacheManager = new DefaultCacheManager(cfg.build());

Cache cache = cacheManager.getCache();
Alternatively, indexing (and everything else) can also be configured via XML configuration, as already described in the user guide, so we'll not delve into details here.

Your Hibernate Search annotated entity might look like this.


import org.hibernate.search.annotations.*;
...

@Indexed
public class User {

    @Field(store = Store.YES, analyze = Analyze.NO)
    private String name;

    @Field(store = Store.YES, analyze = Analyze.NO, indexNullAs = Field.DEFAULT_NULL_TOKEN)
    private String surname;

    @IndexedEmbedded(indexNullAs = Field.DEFAULT_NULL_TOKEN)
    private List addresses;

    // .. the rest omitted for brevity
}
Running a DSL based query involves obtaining a QueryFactory from the (cache scoped) SearchManager and then constructing the query as follows:


import org.infinispan.query.Search;
import org.infinispan.query.dsl.QueryFactory;
import org.infinispan.query.dsl.Query;
...

QueryFactory qf = Search.getSearchManager(cache).getQueryFactory();

Query q = qf.from(User.class)
    .having("name").eq("John")
    .toBuilder().build();

List list = q.list();

assertEquals(1, list.size());
assertEquals("John", list.get(0).getName());
assertEquals("Doe", list.get(0).getSurname());
That's it! I'm sure this raised your curiosity as to what the DSL is actually capable of so you might want to look at the list of supported filter operators in FilterConditionEndContext. Combining multiple conditions with boolean operators, including sub-conditions, is also possible:

Query q = qf.from(User.class)
    .having("name").eq("John")
    .and().having("surname").eq("Doe")
    .and().not(qf.having("address.street").like("%Tanzania%").or().having("address.postCode").in("TZ13", "TZ22"))
    .toBuilder().build();

The DSL is pretty nifty right now and will surely be expanded in the future based on your feedback. It also provides support for result pagination, sorting, projections, embedded objects, all demonstrated in QueryDslConditionsTest which I encourage you to look at until the proper user guide is published. Still, this is not a relational database, so keep in mind that all queries are written in the scope of the single targeted entity (and its embedded entities). There are no joins (yet), no correlated subqueries, no grouping or aggregations.

Moving further, probably the most exciting thing about the new DSL is using it remotely via the Hot Rod client. But to make this leap we first had to adopt a common format for storing our cache entries and marshalling them over the wire that would also be cross-language and robust enough to support evolving object schemas. But probably most of all, this format had to have a schema rather than just being an opaque blob otherwise indexing and searching are meaningless. Enter Protocol Buffers.

The Protobuf marshaller


Configuring the RemoteCacheManager of the Java Hot Rod client to use it is straight forward:

import org.infinispan.client.hotrod.configuration.ConfigurationBuilder;
...

ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder.addServer()
    .host("127.0.0.1").port(11234)
    .marshaller(new ProtoStreamMarshaller());
Now you'll be able to store and get from the remote cache your User instaces encoded in protobuf format provided that:

1. a Protobuf type was declared for your entity in a .proto file which was then compiled into a .protobin binary descriptor

2. the binary descriptor was registered with your RemoteCacheManager's ProtoStreamMarshaller instance like this:

ProtoStreamMarshaller.getSerializationContext(remoteCacheManager)
    .registerProtofile("my-test-schema.protobin");
3. a per-entity marshaller was registered:

ProtoStreamMarshaller.getSerializationContext(remoteCacheManager)
    .registerMarshaller(User.class, new UserMarshaller());
Steps 2 and 3 are closely tied to the way Protosteam library works, which is pretty straight forward but cannot be detailed here. Having a look at our UserMarshaller sample should clear this up.

Keeping your objects stored in protobuf format has the benefit of being able to consume them with compatible clients written in other languages. But if this does not sound enticing enough probably the fact they can now be easily indexed should be more appealing.

Remote querying via the Hot Rod client


Given a RemoteCacheManager configured as previously described the next steps to enable remote query over its caches are:

1. add the DSL jar to client's classpath, infinispan-remote-query-server.jar to server's classpath and infinispan-remote-query-client.jar to both
2. enable indexing in your cache configuration - same as for embedded mode
3. register your protobuf binary descriptor by invoking the 'registerProtofile' method of the server's ProtobufMetadataManager MBean (one instance per EmbeddedCacheManager)

All data placed in cache now is being indexed without the need to annotate your entities for Hibernate Search. In fact these classes are only meaningful to the Java client and do not even exist on the server.

Running the queries over the Hot Rod client is now very similar to embedded mode. The DSL is in fact the same. The only part that is slightly different is how you obtain the QueryFactory:


import org.infinispan.client.hotrod.Search;
import org.infinispan.query.dsl.QueryFactory;
import org.infinispan.query.dsl.Query;
...

remoteCache.put(2, new User("John", "Doe", 33));

QueryFactory qf = Search.getQueryFactory(remoteCache);

Query query = qf.from(User.class)
    .having("name").eq("John")
    .toBuilder().build();

List list = query.list();
assertEquals(1, list.size());
assertEquals("John", list.get(0).getName());
assertEquals("Doe", list.get(0).getSurname());
  
Voila! The end of our journey for today! Stay tuned, keep an eye on Infinispan Query and please share your comments with us.

Friday, 20 September 2013

Heterogenous clusters with Infinispan 6.0.0.Beta1

One of the basic rules of participating in an Infinispan cluster was that everyone must pay their fair share. Sure, each node was able to run a diferent set of caches (i.e. the cluster didn't have to be symmetric). But when a node started up a distributed cache, it automatically took ownership of a share of the keys equal to all the other members of the cache.

With the implementation of ISPN-3051 in 6.0.0.Beta1, that is no longer the case. Each node can now opt to own more or less keys, using the new capacityFactor setting. The default capacity factor is 1.0, and nodes can specify both a higher and a lower value via configuration API:

Or via the XML configuration:
 
Note that we don't guarantee that the number of keys owned by a node will be exactly proportional to its capacity factor. In particular, custom ConsistentHashFactory implementations are free to ignore the capacityFactor setting completely. But the default ConsistentHashFactory will try to respect it as much as it can.

One interesting use case is nodes with a capacity factor of 0. This could be useful when some nodes are too short-lived to be useful as data owners, but they can't use HotRod (or other remote protocols) because they need transactions. With cross-site replication as well, the "site master" should only deal with forwarding commands between sites and shouldn't handle user requests, so it makes sense to configure it with a capacity factor of 0.

A final note: Infinispan server 6.0.0.Beta1 also supports this feature, but the setting is called capacity-factor to match the AS naming convention.

Thursday, 19 September 2013

Infinispan 6.0.0.Beta1 is out!

Dear Infinispan community,

We are proud to announce the first Beta release of Infinispan 6.0.0. This is an important milestone in the 6.0.0 lifecycle: it is feature and API complete.

Included in this release, you can find:
  • a complete implementation of the remote-query functionality, including index management through JMX .  Adrian Nistor will blog on this in the following days
  • allow configuring the number of segments per node allows one to configure an uneven load of data between the nodes int the cluster. Dan Berindei will add a blog on this shortly
Together with this release we're also launching our new website:
  •  Built with Awestruct.  Yes, it really is awesome and fun to use
  •  Hosted on GitHub Pages.  Quick and easy.
  •  Styled with JBoss.org Community's flavour of Twitter Bootstrap 
  •  Documentation reformatted/moved from Confluence to AsciiDoc 
Among other things, the new site reflects some changes in the way Infinispan is distributed - including several cache stores and Hot Rod clients being moved out to separate GitHub repositories and following their own release cycles. 
We think it's pretty slick and pretty sure you wouldn't guess its written by a hardcore backed developer! Kudos to Manik Surtani for such a nice job!

Last but certainly not least,  a BIG thanks to our colleagues from the Hibernate team for their support (that is enhancements, fixes and releases and unreasonable hours) in getting the support needed for Infinispan's remote query functionality in time!

For a complete list of features and fixes included in this release please 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.

Thanks to everyone for their involvement and contribution!

Cheers,
Mircea

Monday, 16 September 2013

New persistence API in Infinispan 6.0.0.Alpha4

The existing CacheLoader/CacheStore API has been around since Infinispan 4.0. In this release of Infinispan we've taken a major step forward in both simplifying the integration with persistence and opening the door for some pretty significant performance improvements.

What's new


So here's what the new persistence integration brings to the table:
  • alignment with JSR-107: now we have a CacheWriter and CacheLoader interface similar to the the loader and writer in JSR 107, which should considerably help writing portable stores across JCache compliant vendors
  • simplified transaction integration: all the locking is now handled within the Infinispan layer, so implementors don't have to be concerned coordinating concurrent access to the store (old LockSupportCacheStore is dropped for that reason).
  • parallel iteration: it is now possible to iterate over entries in the store with multiple threads in parallel. Map/Reduce tasks immediately benefit from this, as the map/reduce  tasks now run in parallel over both the nodes in the cluster and within the same node (multiple threads)
  • reduced serialization (translated in less CPU usage): the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly

API


Now let's take a look at the API in more detail:



  The diagram above shows the main classes in the API:
  • ByteBuffer - abstracts the serialized form on an object
  • MarshalledEntry - abstracts the information held within a persistent store corresponding to a key-value added to the cache. Provides method for reading this information both in serialized (ByteBuffer) and deserialized (Object) format. Normally data read from the store is kept in serialized format and lazily deserialized on demand, within the MarshalledEntry implementation
  •  CacheWriter and CacheLoader  provide basic methods for reading and writing to a store
  • AdvancedCacheLoader and AdvancedCacheWriter provide operations to manipulate the underlaying storage in bulk: parallel iteration and purging of expired entries, clear and size. 
A provider might choose to only implement a subset of these interfaces:
  • Not implementing the  AdvancedCacheWriter makes the given writer not usable for purging expired entries or clear
  • Not implementing  the AdvancedCacheLoader makes the information stored in the given loader not used for preloading, nor for the map/reduce iteration
If you're looking at migrating your existing store to the new API, looking at the SingleFileStore  for inspiration can be of great help.

Configuration


And finally, the way the stores are configured has changed:
  • the 5.x loaders element is now replaced with persistence
  • both the loaders and writers are configured through a unique store element  (vs loader and  store, as allowed in 5.x)
  • the preload and shared attributes are configured at each individual store, giving more flexibility when it comes to configuring multiple chained stores 
Cheers,
Mircea

Monday, 9 September 2013

Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!

Infinispan 6.0.0.Alpha4 is now with a few very important changes, particularly around cache stores. We've completely revamped the cache store/loader API to align it a bit better with JSR-107 (old CacheStore has become CacheWriter) and to simplify creation of new implementations. The new CacheLoader and CacheWriter should help implementors focus on the important operations and reduce the coding time. We've also created AdvancedCacheLoader and AdvancedCacheWriter in order to separate for bulk operations or purging for those implementations that wish optionally implement them. Expect a blog post from Mircea in the next few days providing many more details on this topic.

This new Infinispan version comes with other important goodies:
  • Rolling upgrades of a Infinsipan REST cluster
  • Support for Cache-Control headers for REST operations
  • Remote querying server modules and Hot Rod client update
  • REST and LevelDB stores added to Infinispan Server
  • KeyFilters can now be applied to Cache listeners
  • Allow Cache listener events to be invoked only on the primary data owner
For a complete list of features and fixes included in this release please 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,
Galder

Thursday, 22 August 2013

Infinispan 6.0.0.Alpha3 is out!

Dear Infinispan community,

We are proud to announce the last Alpha release of Infinispan 6.0.0,

Included in this release, we can find:

  • The most recent improvements from Hibernate and JGroups modules.
  • A step closer toward to querying over the Hotrod protocol.
  • And other important fixes and enhancements.
For a complete list of features and fixes included in this release please 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.

Thanks to everyone for their involvement and contribution!

Cheers,
Pedro

Monday, 5 August 2013

Infinispan 6.0.0.Alpha2 is out!

Dear Infinispan community,

We're proud to announce the second Alpha release of Infinispan 6.0.0, and also the second release using the Apache Software Licence.


New features in this release:

  • A new query DSL that is usable both in embedded/library mode and over HotRod.
  • Support for JCache 0.8, the Public Review Draft version of the JSR-107 specification.
  • A slimmer distribution, thanks to moving non-core cache store implementations to separate repositories.
For a complete list of features and fixes included in this release please 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.


Thanks to everyone for their involvement and contribution!


Cheers
Dan

Thursday, 18 July 2013

Faster file cache store (no extra dependencies!) in 6.0.0.Alpha1

As announced yesterday by Adrian, the brand new Infinispan 6.0.0.Alpha1 release contains a new file-based cache store which needs no extra dependencies. This is essentially a replacement of the existing FileCacheStore which didn't perform as expected, and caused major issues due to the number of files it created.

The new cache store, contributed by a Karsten Blees (who also contributed an improved asynchronous cache store), is called SingleFileCacheStore and it keeps all data in a single file. The way it looks up data is by keeping an in-memory index of keys and the positions of their values in this file. This design outperforms the existing FileCacheStore and even LevelDB based JNI cache store.

The classic case for a file based cache store is when you want to have a cache with a cache store available locally which stores data that has overflowed from memory, having exceeded size and/or time restrictions. We ran some performance tests to verify how fast different cache store implementations could deal with reading and writing overflowed data, and these are the results we got (in Ks):

  • FileCacheStore: 0.75k reads/s, 0.285k writes/s
  • LevelDB-JNI impl: 46k reads/s, 15.2k writes/s
  • SingleFileCacheStore: 458k reads/s, 137k writes/s
The difference is quite astonishing but as already hinted, this performance increase comes at a cost. Having to maintain an index of keys and positions in the file in memory has a cost in terms of extra memory required, and potential impact on GC. That's why the SingleFileCacheStore is not recommended for use cases where the keys are too big.

In order to help tame this memory consumption issues, the size of the cache store can be optionally limited, providing a maximum number of entries to store in it. However, setting this parameter will only work in use cases where Infinispan is used as a cache. When used as a cache, data not present in Infinispan can be recomputed or re-retrieved from the authoritative data store and stored in Infinispan cache. The reason for this limitation is because once the maximum number of entries is reached, older data in the cache store is removed, so if Infinispan was used as an authoritative data store, it would lead to data loss which is not good.

Existing FileCacheStore users might wonder: what is it gonna happen to the existing FileCacheStore? We're not 100% sure yet what we're going to do with it, but we're looking into some ways to migrate data from the FileCacheStore to the SingleFileCacheStore. Some interesting ideas have already been submitted which we'll investigate in next Infinispan 6.0 pre-releases.

So, if you're a FileCacheStore user, give the new SingleFileCacheStore a go and let us know how it goes! Switching from one to the other is easy :)

Cheers,
Galder

Wednesday, 17 July 2013

Infinispan 6.0.0.Alpha1 is out!

Dear Infinispan community,

We're proud to announce the first Alpha release of Infinispan 6.0.0. Starting with this release, Infinispan license is moving to the terms of the Apache Software Licence version 2.0.

Besides increased stability (about 30 bug fixes) this release also brings several new features:

  • A more efficient FileCacheStore implementation (courtesy Karsten Blees)
  • A new set of usage and performance statistics developed within the scope of the CloudTM project
  • A new (experimental) marshaller for Hot Rod based on protobuf, which will be primarily used by the upcoming remote querying feature. Since this has reuse potential in other projects it was promoted to an independent project named protostream under the Infinispan umbrella
For a complete list of features and fixes included in this release please 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.

Thanks to everyone for their involvement and contribution!

Cheers,
Adrian

Friday, 12 July 2013

Store data by reference or by value?

Traditionally, Infinispan has always stored data by-reference. Once clients store some data, clients can still modify entries via original object references. This means that since client references are valid, clients can make changes to entries in the cache using those references, but these modifications are only local and you still need to call one of the cache's put/replace... methods in order for changes to replicate.

Obviously, allowing clients to modify cache contents directly, without any cache invocation, has some risks and that's why starting with Infinispan 5.3.0.Final, it offers the possibility to store data by-value instead. The way store-by-value is enabled is by enabling Infinispan to store data in binary format and forcing it to do these binary transformations eagerly.

We've also added an FAQ entry that clarifies this topic.

Cheers,
Galder

Tuesday, 2 July 2013

Lower memory overhead in Infinispan 5.3.0.Final

Infinispan users worried about memory consumption should upgrade to Infinispan 5.3.0.Final as soon as possible, because as part of the work we've done to support storing byte arrays without wrappers, and the development of the interoperability mode, we've been working to reduce Infinispan's memory overhead.

To measure overhead, we've used Martin Gencur's excellent memory consumption tests. The results for entries with 512 bytes are:

Infinispan memory overhead, used in library mode:
Infinispan 5.2.0.Final: ~151 bytes
Infinispan 5.3.0.Final: ~135 bytes
Memory consumption reduction: ~12%

Infinispan memory overhead, for the Hot Rod server:
Infinispan 5.2.0.Final: ~174 bytes
Infinispan 5.3.0.Final: ~151 bytes
Memory consumption reduction: ~15%

Infinispan memory overhead, for the REST server:
Infinispan 5.2.0.Final: ~208 bytes
Infinispan 5.3.0.Final: ~172 bytes
Memory consumption reduction: ~21%

Infinispan memory overhead, for the Memcached server:
Infinispan 5.2.0.Final: ~184 bytes
Infinispan 5.3.0.Final: ~180 bytes
Memory consumption reduction: ~2%

This is great news for the Infinispan community but our effort doesn't end here. We'll be working on further improvements in next releases to bring down cost even further.

Cheers,
Galder

Wednesday, 26 June 2013

Infinispan 5.3.0.Final is out!

Dear Infinispan community,

We're proud to announce the final release of Infinispan 5.3.0 "Tactical Nuclear Penguin". Besides increased stability (130+ bug fixes) this release also brings some highly demanded 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.

Time to move forward now: Infinispan 6.0 will bring some significant improvements to the Inifinispan ecosystem  and also a shift in licence to Apache Software Licence 
Stay tuned!

Cheers,
Mircea

Monday, 17 June 2013

Infinispan 5.3.0.CR2 is out!

Planned to be the last from the 5.3 series, the 5.3.CR2 release contains:
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

Tuesday, 11 June 2013

Introducing LevelDB Cache Store


Infinispan 5.3.0 will be introducing a LevelDB cache store.  This cache store will allow you to store cache entries using a fast filesystem based LevelDB key-value store originally developed by Google.  This cache store uses a Java implementation of LevelDB, and maybe one day, it can get even better performance by using the JNI implementation.

Configuration is simple:
Please see documentations for detailed sample usage and configuration.

Hope you enjoy this new addition!

Ray

Tuesday, 4 June 2013

Using MongoDB as a cache store

With the 5.3 release, there is a brand new feature. I'm glad to announce that you will be able to use MongoDB as a cache store.

For those who don't know MongoDB, it's an open-source document oriented NoSQL database developped by 10Gen. You can more information about it on http://www.mongodb.org/.

The question you have right now, it probably, how to use it cool cache store ? Simple, as for the other cache store you have to add a loader in your Infinispan configuration file.

Here is an exemple:

If you prefer the programmatic API:
For more information about the configuration possibilities (default values, options, etc) , you can refer to the documentation page

Cheers,
Guillaume
Hibernate OGM & Infinispan contributor
Blog / @g_scheibel

Thursday, 30 May 2013

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

Tuesday, 28 May 2013

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

Thursday, 23 May 2013

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

Monday, 20 May 2013

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

Friday, 17 May 2013

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

Friday, 10 May 2013

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

Friday, 3 May 2013

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