I'm happy to announce a new release (the first feature-complete!) of Infinispan Spring Boot Starters.
We finally added new properties for managing Hot Rod client mode in application.properties as well Spring Cache automatic support. Finally, we fixed a couple of smaller issues.
For complete changelog, please refer to the release page.
The artifacts should be available in Maven Central as soon as the sync completes. In the meantime grab them from JBoss Repository.
Wednesday, 15 March 2017
KUBE_PING 0.9.2 released!
I'm happy to announce a new release of KUBE_PING JGroups protocol.
Since this is a minor maintenance release, there are no ground breaking changes but we fixed a couple of issues that prevented our users from using JGroups 3.6.x and KUBE_PING 0.9.1.
Have a look at the release page to learn more details.
The artifacts should be available in Maven Central as soon as the sync completes. In the meantime grab them from JBoss Repository.
Since this is a minor maintenance release, there are no ground breaking changes but we fixed a couple of issues that prevented our users from using JGroups 3.6.x and KUBE_PING 0.9.1.
Have a look at the release page to learn more details.
The artifacts should be available in Maven Central as soon as the sync completes. In the meantime grab them from JBoss Repository.
Hotrod clients C++/C# 8.1.0.CR2 released!
Dears,
we're pleased to announce that 8.1.0.CR2 release for C++/C# clients is out!
Check the release notes, focus was on bug fixes this round so you have the opportunity to download the cleanest code so far!
Spring cleaning will continue in the next release iteration, stay tuned and, if you like, take part signalling new issues here!
Enjoy!
The Infinispan Team
we're pleased to announce that 8.1.0.CR2 release for C++/C# clients is out!
Check the release notes, focus was on bug fixes this round so you have the opportunity to download the cleanest code so far!
Spring cleaning will continue in the next release iteration, stay tuned and, if you like, take part signalling new issues here!
Enjoy!
The Infinispan Team
Friday, 10 March 2017
JDBC Migrator or: How I Learned to Stop Worrying About Buckets and Utilise the JdbcStringBasedStore!
Infinispan 9 has introduced many improvements to its marshalling codebase in order to improve performance and allow for greater flexibility. Consequently, data marshalled and persisted by Infinispan 8.x is no longer compatible with Infinispan 9.x. Furthermore, as part of our ongoing efforts to improve the cache stores provided by Infinispan, we have removed both the JdbcBinaryStore and JdbcMixedStore in Infinispan 9.0.
To assist users migrating from Infinispan 8.x, we have created the JDBC Migrator that enables existing JDBC stores to be migrated to Infinispan 9's JdbcStringBasedStore.
The original intention of the JdbcBinaryStore was to provide greater flexibility over the JdbcStringBasedStore as it did not require a Key2StringMapper implementation. This was achieved by utilising the hashcode of an entries key for a table's ID column entry. However, due to the possibility of hash collisions all entries had to be placed inside a Bucket object which was then serialised and inserted into the underlying table. Utilising buckets in this manner was far from optimal as each read/write to the underlying table required an existing bucket for a given hash to be retrieved, deserialised, updated, serialised and then re-inserted back into the db.
To assist users migrating from Infinispan 8.x, we have created the JDBC Migrator that enables existing JDBC stores to be migrated to Infinispan 9's JdbcStringBasedStore.
No More Binary Keyed Stores!
The original intention of the JdbcBinaryStore was to provide greater flexibility over the JdbcStringBasedStore as it did not require a Key2StringMapper implementation. This was achieved by utilising the hashcode of an entries key for a table's ID column entry. However, due to the possibility of hash collisions all entries had to be placed inside a Bucket object which was then serialised and inserted into the underlying table. Utilising buckets in this manner was far from optimal as each read/write to the underlying table required an existing bucket for a given hash to be retrieved, deserialised, updated, serialised and then re-inserted back into the db.
Introducing JDBC Migrator
The JDBCMigrator is a standalone application that takes a single argument, the path to a .properties file which must contain the configuration properties for both the source and target stores. To use the migrator you need the infinispan-tools-9.x.jar, as well as the jdbc drivers required by your source and target databases, on your classpath.
An example maven pom that launches the migrator via mvn exec:java is presented below:
Below are several example .properties files used for migrating various stores, however an exhaustive list of all available properties can be found in the Infinispan user guide.
An example maven pom that launches the migrator via mvn exec:java is presented below:
Migration Examples
Below are several example .properties files used for migrating various stores, however an exhaustive list of all available properties can be found in the Infinispan user guide.
Before attempting to migrate your existing stores please ensure you have backed up your database!
8.x JdbcBinaryStore -> 9.x JdbcStringBasedStore
The most important property to set in this example is "source.marshaller.type=LEGACY" as this instructs the migrator to utilise the Infinispan 8.x marshaller to unmarshall data stored in your existing DB tables.
If you specified custom AdvancedExternalizer implementations in your Infinispan 8.x configuration, then it is necessary for you to specify these in the migrator configuration and ensure that they are available on the migrators classpath. To Specify the AdvancedExternalizers to load, it is necessary to define the "source.marshaller.externalizers" property with a comma-separated list of class names. If an ID was explicitly set for your externalizer, then it is possible to prepend the externalizers class name with "<id>:" to ensure the IDs is respected by the marshaller.
TwoWayKey2StringMapper Migration
As well as using the JDBC Migrator to migrate from Infinispan 8.x, it is also possible to utilise it to migrate from one DB dialect to another or to migrate from one TwoWayKey2StringMapper implementation to another.
Summary
Infinispan 9 stores are no longer compatible with Infinispan 8.x stores due to internal marshalling changes. Furthermore, the JdbcBinary and JdbcMixed stores have been removed due to their poor performance characteristics. To aid users in their transition from Infinispan 8.x we have created the JDBC Migrator to enable users to migrate their existing JDBC stores.
If you're a user of the JDBC stores and have any feedback on the latest changes, let us know via the forum, issue tracker or the #infinispan channel on Freenode.
If you're a user of the JDBC stores and have any feedback on the latest changes, let us know via the forum, issue tracker or the #infinispan channel on Freenode.
Wednesday, 1 March 2017
Checking Infinispan cluster health and Kubernetes/OpenShift
Modern applications and microservices often need to expose their health status. A common example is Spring Actuator but there are also many different ways of doing that.
Starting from Infinispan 9.0.0.Beta2 we introduced the HealthCheck API. It is accessible in both Embedded and Client/Server mode.
Cluster Health and Embedded Mode
The HealthCheck API might be obtained directly from EmbeddedCacheManager and it looks like this:
The nice thing about the API is that it is exposed in JMX by default:
More information about using HealthCheck API in Embedded Mode might be found here:
Cluster Health and Server Mode
Since Infinispan is based on Wildfly, we decided to use CLI as well as built-in Management REST interface.
Here's an example of checking the status of a running server:
Querying the HealthCheck API using the Management REST is also very simple:
Note that for the REST endpoint, you have to use proper credentials.
More information about the HealthCheckA API in Server Mode might be found here:
Cluster Health and Kubernetes/OpenShift
Monitoring cluster health is crucial for Clouds Platforms such as Kubernetes and OpenShift. Those Clouds use a concept of immutable Pods. This means that every time you need change anything in your application (changing configuration for the instance), you need to replace the old instances with new ones. There are several ways of doing that but we highly recommend using Rolling Updates. We also recommend to tune the configuration and instruct Kubernetes/OpenShift to replace Pods one by one (I will show you an example in a moment).
Our goal is to configure Kubernetes/OpenShift in such a way, that each time a new Pod is joining or leaving the cluster a State Transfer is triggered. When data is being transferred between the nodes, the Readiness Probe needs to report failures and prevent Kubernetes/OpenShift from doing progress in Rolling Update procedure. Once the cluster is back in stable state, Kubernetes/OpenShift can replace another node. This process loops until all nodes are replaced.
Luckily, we introduced two scripts in our Docker image, which can be used out of the box for Liveness and Readiness Probes:
At this point we are ready to put all the things together and assemble DeploymentConfig:
Interesting parts of the configuration:
- lines 13 and 14: We allocate additional capacity for the Rolling Update and allow one Pod to be down. This ensures Kubernetes/OpenShift replaces nodes one by one.
- line 44: Sometimes shutting a Pod down takes a little while. It is always better to wait until it terminates gracefully than taking the risk of losing data.
- lines 45 - 53: The Liveness Probe definition. Note that when a node is transferring the data it might highly occupied. It is wise to set higher value of 'failureThreshold'.
- lines 54 - 62: The same rule as the above. The bigger the cluster is, the higher the value of 'successThreshold' as well as 'failureThreshold'.
Feel free to checkout other articles about deploying Infinispan on Kubernetes/OpenShift:
- http://blog.infinispan.org/2016/08/running-infinispan-cluster-on-openshift.html
- http://blog.infinispan.org/2016/08/running-infinispan-cluster-on-kubernetes.html
- http://blog.infinispan.org/2016/09/configuration-management-on-openshift.html
- http://blog.infinispan.org/2016/10/openshift-and-node-affinity.html
- http://blog.infinispan.org/2016/07/bleeding-edge-on-docker.html
Thursday, 23 February 2017
Node.js client 0.4.0 released with encryption and cross-site failover
We've just released Infinispan Node.js Client version 0.4.0 which comes with encrypted client connectivity via SSL/TLS (with optional TLS/SNI support), as well as cross-site client failover.
Thanks to the encryption integration, Node.js Hot Rod clients can talk to Hot Rod servers via an encrypted channel, allowing trusted client and/or authenticated clients to connect. Check the documentation for information on how to enable encryption in Node.js Hot Rod client.
Also, we've added the possibility for the client to connect to multiple clusters. Normally, the client is connected to a single cluster, but if all nodes fail to respond, the client can failover to a different cluster, as long as one or more initial addresses have been provided. On top of that, clients can manually switch clusters using switchToCluster and switchToDefaultCluster APIs. Check documentation for more info.
On top of that, we've applied several bug fixes that further tighten the inner workings of the Node.js client.
If you're a Node.js user and want to store data remotely in Infinispan Server instances, please give the client a go and tell us what you think of it via our forum, via our issue tracker or via IRC on the #infinispan channel on Freenode.
Thanks to the encryption integration, Node.js Hot Rod clients can talk to Hot Rod servers via an encrypted channel, allowing trusted client and/or authenticated clients to connect. Check the documentation for information on how to enable encryption in Node.js Hot Rod client.
Also, we've added the possibility for the client to connect to multiple clusters. Normally, the client is connected to a single cluster, but if all nodes fail to respond, the client can failover to a different cluster, as long as one or more initial addresses have been provided. On top of that, clients can manually switch clusters using switchToCluster and switchToDefaultCluster APIs. Check documentation for more info.
On top of that, we've applied several bug fixes that further tighten the inner workings of the Node.js client.
If you're a Node.js user and want to store data remotely in Infinispan Server instances, please give the client a go and tell us what you think of it via our forum, via our issue tracker or via IRC on the #infinispan channel on Freenode.
Infinispan 9.0 CR2 is out!
Dear community.
We are one step closer to the final release of Infinispan 9: we gladly announce the release of Infinispan 9.0.0.CR2.
We are one step closer to the final release of Infinispan 9: we gladly announce the release of Infinispan 9.0.0.CR2.
The highlights of this release are:
- Many dependencies have been upgraded to the latest and greatest:
- JGroups 4.0.0.Final
- Apache Lucene 5.5.4
- Hibernate Search 5.7.0.Final
- Protostream 4.0.0.Alpha7
- Transactional caches changes:
- Removed asynchronous configuration since it won't be supported anymore.
- Introduced EmbeddedTransactionManager: a basic transaction manager implementation.
- Query now supports java.time.Instant natively
- Changes in the configuration;
- Significant performance improvements for embedded and client/server mode;
- And finally, quite a few bug fixes preparing us for the final release !
You can read all about these in the release notes.
Keep an eye on the upgrade guide and start prepare your project for the final Infinispan 9 release.
So, please head over to the download page and try it out. If you have an issue, please report it in our bug tracker, ask us on the forum, or join us for a friendly chat on the #infinispan IRC channel on Freenode.
Regards,
Infinispan Team.
So, please head over to the download page and try it out. If you have an issue, please report it in our bug tracker, ask us on the forum, or join us for a friendly chat on the #infinispan IRC channel on Freenode.
Regards,
Infinispan Team.
Subscribe to:
Posts (Atom)