Friday, 17 April 2015
We are proud to announce the release of Infinispan 7.2.0.CR1!
This is the first release candidate of 7.2, bringing some exciting new features:
Cache creation and configuration changes without the need to restart the server (ISPN-5147)
Lock-free clear() operation (ISPN-5370)
For the complete list of features and bug fixes, please refer to the release notes
Tags: getAll hotrod putAll listeners release candidate DSL
Tuesday, 17 March 2015
Dear Infinispan community,
We are proud to announce the release of Infinispan 7.2.0.Beta1 today.
Along the usual assortment of bug fixes, this release includes a few exciting new features:
For a complete list of features and bug fixes included in this release, please refer to the release notes.
Many thanks to everyone who contributed to this release!
Tags: release hotrod scripting eviction jcache
Monday, 15 December 2014
This blog post is the last in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. First article focused on how to get started receiving remote events from Hot Rod servers. The second article looked at how Hot Rod remote events can be filtered, and the third one showed how to customize contents of events.
In this last article, we’ll be focusing on how remote events are fired in a clustered environment and how failover situations are dealt with.
The most important thing to know about remote events in a clustered environment is that when a client adds a remote listener, this is installed in a single node in the cluster and that this node is in charge of sending events back to the client for all affected operations happening cluster wide.
As a result of this, when filtering or event customization is applied, the org.infinispan.notifications.cachelistener.filter.CacheEventFilter and/or org.infinispan.notifications.cachelistener.filter.CacheEventConverter instances must be somehow marshallable. This is necessary because when the client listener is installed in a cluster, the filter and/or converter instances are sent to other nodes in the cluster so that filtering and conversion can happen right where the event originates, hence improving efficiency. These classes can be made marshallable by making them extend Serializable, or providing and registering a custom Externalizer for them.
Under normal circumstances, the code and examples showed in previous blog posts work the same way in clustered environment. However, in a clustered environment, a decision needs to be made with regards to how to deal with situations where nodes go down: If a node goes down that does not have the client listener installed, nothing happens. However, when the node containing the client listener goes down, the Hot Rod client implementation transparently fails over the client listener registration to a different node. As a result of this failover, there could be a gap in the event consumption. This gap is solved using one of these solutions:
The @ClientListener annotation has an optional parameter called includeCurrentState. When this is enabled and the client listener is registered, before receiving any events for on-going operations, the server sends ClientCacheEntryCreatedEvent event instances (for methods annotated with @ClientCacheEntryCreated) for all existing cache entries to the client. This offers the client an opportunity to construct some state or computation based on the contents of the clustered cache. When the Hot Rod client transparently fails over registered listeners, it re-registers them in a different node and if includeCurrentState is enabled, clients can recompute their state or computation to reinstate it to what it was before the failover. The downside of includeCurrentState is that it’s performance is heavily dependant on the cache size, and hence it’s disabled by default.
Alternatively, instead of relying on receiving state, users can define a method with @ClientCacheFailover annotation that receives ClientCacheFailoverEvent as parameter inside the client listener implementation:
This method would be called back whenever the node that had this client listener has gone down. This can be handy for situations when the end users just wants to clear up some local state as a result of the failover, e.g. clear a near or L1 cache. When events are received again, the near or L1 cache could be repopulated again.
This callback method of dealing with client listener failover offers a simple, efficient solution to dealing with cluster topology changes affecting client listeners. Depending on the remote event use case, this method might be better suited that state delivery.
This post marks the end of the remote event series. In future Infinispan versions, we’ll continue improving the technology adding some extra features, and more importantly, we’ll start building higher level abstractions on top of remote events, such as Hot Rod client Near Caches.
Tags: hotrod event remote events failover
Tuesday, 28 October 2014
Infinispan HotRod .NET Client 7.0.0.CR2 is now available.
This is mostly a bug-fix release.For the complete list of changes please consult the release notes (includes also the changes from the corresponding version of the C++ Client). Visit our downloads section to find the latest release. If you have any questions please check our forums, our mailing lists or ping us directly on IRC.
Thanks to everyone involved for the changes and bug reports contributed!
Tags: hotrod dotnet-client release candidate
Monday, 27 October 2014
Infinispan HotRod C++ Client 7.0.0.CR2 is now available.
This is mostly a bug-fix release. I would like bring to your attention the following changes:
For the complete list of changes please consult the release notes. Visit our downloads section to find the latest release. If you have any questions please check our forums, our mailing lists or ping us directly on IRC.
Thanks to everyone involved for the changes and bug reports contributed!
Tags: hotrod cpp-client release candidate
Wednesday, 14 May 2014
It is our pleasure to announce the Alpha4 release of Infinispan 7.0.0.
The release highlights are:
HotRod protocol now supports authorization and the SKIP_CACHE_LOAD flag;
Distributed entry iterator which allows iterate over all entries in the cluster;
Object filtering and preview using query DSL;
Apache Lucene 4.8.0 is now supported and JGroups was upgraded to 3.5.0.Beta5;
Multiple improvements and bug fixes!
The Infinispan team.
Tags: security hotrod infinispan
Thursday, 06 March 2014
Infinispan 7.0.0.Alpha1 makes it possible to easily run the HotRod client in an OSGi based container such as Karaf. Until this point there was no easy way to find out which libraries were required for the HotRod client to run in OSGi. These libraries then had to be installed manually and dynamic imports enabled for all the libraries. Last but not least, it was not possible to use the latest HotRod feature - remote queries.
The 7.0.0.Alpha1 introduces a "features" file which not only lists all dependencies required for correct functionality of the HotRod client in OSGi, but also makes it very easy to install the whole feature into Karaf (version 2.3.3 or 3.0) in just a few steps.
The feature file has been deployed into JBoss Nexus repository so it’s publicly available. It looks like this:
The HotRod feature (either a simple HotRod client or HotRod client with remote query capabilities) can be installed in Karaf in the following steps:
There’s still one limitation with respect to remote querying, though. The remote query feauture requires a JMX-based connection to Infinispan server in order to be able to register a .protobin file, which holds the description of data types being transferred between the client and server. Since a remoting-jmx protocol is required and the existing remoting-jmx client does not work correctly in OSGi (see https://issues.jboss.org/browse/ISPN-4011), it is required to register the .protobin file in another way - not from inside the OSGi container. This will be fixed in one of the next releases.
Stay connected for news about running the whole Infinispan datagrid in OSGi, not only the HotRod client. This is work in progress.
Tags: hotrod osgi
Wednesday, 05 March 2014
Infinispan HotRod C# Client 7.0.0.Alpha1 is now available. This new version is a C# wrapper over the native client and brings support for L2 and L3 client intelligence levels in addition to L1. As more features are added to the native client they will make their way into the C# client as well.
Tags: csharp hotrod alpha
Monday, 13 January 2014
Following up on the previous post on Infinispan remote queries, we’ve prepared a quick start guide to get you up and running with remote queries in minutes.
It’s a simple Java application that places some data in a remote cache and then retrieves it using queries over Hot Rod. On top of that, the project also contains a C companion app contributed by https://github.com/isavin[Ion Savin] that uses the https://github.com/infinispan/cpp-client/[C Hot Rod client] and is able to read and write (but not query, yet) the same data, demonstrating interoperability between C and Java clients. At this point the Protobuf encoding support comes in a few C external helper classes rather than being part of the C++ client, but this is going to improve in the upcoming versions. The code for this app is hosted on Github under the jboss-jdg-quickstarts project. Please note this tutorial was written for the JBoss Data Grid (JDG), but it applies to Infinispan as well. We welcome you to try it and let us know what you think!
Tags: jdg hotrod quick start cpp-client remote query
Tuesday, 19 November 2013
Dear Infinispan community,
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 projecthttps://issues.jboss.org/browse/ISPN-3234.
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.
Tags: hotrod persistence jsr 107 jcache Protobuf remote query query