Chapter 21. Compatibility Mode
Compatibility mode is deprecated and will be removed from Red Hat Data Grid. To achieve interoperability between remote endpoints, you should use protocol interoperability capabilities. See Protocol Interoperability.
Compatibility mode configures Red Hat Data Grid caches so that you can access Red Hat Data Grid in multiple ways. Achieving such compatibility requires extra work from Red Hat Data Grid in order to make sure that contents are converted back and forth between the different formats of each endpoint and this is the reason why compatibility mode is disabled by default.
21.1. Enable Compatibility Mode
For compatibility mode to work as expected, all endpoints need to be configured with the same cache manager, and need to talk to the same cache. If you’re using the brand new Red Hat Data Grid Server distribution , this is all done for you. If you’re in the mood to experiment with this in a standalone unit test, this class shows you how you can start multiple endpoints from a single class.
So, to get started using Red Hat Data Grid’s compatibility mode, it needs to be enabled, either via XML:
infinispan.xml
<local-cache> <compatibility/> </local-cache>
Or programmatically:
ConfigurationBuilder builder = ... builder.compatibility().enable();
The key thing to remember about Red Hat Data Grid’s compatibility mode is that where possible, it tries to store data unmarshalling or deserializing it. It does so because the most common use case is for it to store Java objects and having Java objects stored in deserialized form means that they’re very easy to use from an embedded cache. With this in mind, it makes some assumptions. For example, if something is stored via Hot Rod, it’s most likely coming from the reference Hot Rod client, which is written in Java, and which uses a marshaller that keeps binary payloads very compact. So, when the Hot Rod operation reaches the compatibility layer, it will try to unmarshall it, by default using the same default marshaller used by the Java Hot Rod client, hence providing good out-of-the-box support for the majority of cases.
21.1.1. Optional: Configuring Compatibility Marshaller
It could happen though the client might be using a Hot Rod client written for another language other than Java, say Ruby or Python . In this case, some kind of custom marshaller needs to be configured that either translates that serialized payload into a Java object to be stored in the cache, or keeps it in serialized form. Both options are valid, but of course it will have an impact on what kind of objects are retrieved from Red Hat Data Grid if using the embedded cache. The marshaller is expected to implement this interface. Configuring the compatibility marshaller is optional and can be done via XML:
infinispan.xml
<local-cache> <compatibility marshaller="com.acme.CustomMarshaller"/> </local-cache>
Or programmatically:
ConfigurationBuilder builder = ... builder.compatibility().enable().marshaller(new com.acme.CustomMarshaller());
One concrete example of this marshaller logic can be found in the SpyMemcachedCompatibleMarshaller . Spy Memcached uses their own transcoders in order to marshall objects, so the compatibility marshaller created is in charge of marshalling/unmarshalling data stored via Spy Memcached client. If you want to retrieve data stored via Spy Memcached via say Hot Rod, you can configure the Java Hot Rod client to use this same marshaller, and this is precisely what the test where the Spy Memcached marshaller is located is demonstrating.
21.2. Code examples
The best code examples available showing compatibility in action can be found in the Red Hat Data Grid Compatibility Mode testsuite, but more will be developed in the near future.
