-
1. Re: Infinispan Incompatibility and Instability
I am encountering several incompatibilities and instabilities in Infinispan. This is making my original selection of Inifinispan look bad. Examples:
- Programming Language Incomptibilty: When using HotRod client to put and get from Cache. Putting via Java, C#, C++ and Python with the same String key are not readable by different language (causes Exceptions or sometimes worse (hanging in a function call). Only C++ String and Python string seem to store the "same" type of key object on the server side. However, this key object is not understood by the Java side. This led me to almost abandon the idea of multi language (Java on server side was ok, but definitely needed C# clients to work seamlessly.
Providing transparent cross-language compatibility for any object you decide to store in the cache is impossible without a common serialization format. Even something like a simple string is represented in different ways across different languages/platforms. I suggest you look at how Infinispan supports ProtoBuf schemas and marshallers and work from there.
- Cache incompatibily: This was looking bad, till I decided to use the REST interface. At least then all the languages could use the web interface - bypassing the bugs in the Infinispan code. However, using the REST interface completely rules out using the HOTROD client. (and vice versa). Even if a single cache entry is added using HotRod interface, then the REST interface hangs. And vice-versa.
Have you enabled compatibility mode on the server ? It is essential for cross-protocol interoperability.
- This is very crappy indeed. The whole elaborate structure of Distribuion, Replication, Expiration, etc. is pretty useless, if I am limited to single programming language and only one of the cache types (and a single entry using another cache API stops the other one dead in its tracks.
I will ignore the rudeness since, from the questions you have posted above it is more due from lack of understanding of the core principles of how we provide cross-language/cross-protocol and cross-platform compatibility. If Infinispan's clustering, expiration, and other advanced features are not useful to you, and you are looking for a single-node way to store data, you're better off looking at things like Redis. Obviously don't expect it to scale as much as Infinispan.
- Is this done on purpose - i.e. is there a better version that is available to paying clients. Or are there other reasons for this issues (e.g. Infinispan is targetted ONLY to Java users - so programminglanguage incompatibbility is not and issue, and there is no conceivable scenario to use Remote and Rest interface to access the cache)?
Red Hat, the company sponsoring Infinispan's development, is a pure open-source company. This means that the community and product versions share exactly the same codebase and features, unlike some other "open-core" vendors who keep features back from the open source version. What you get when you purchase a subscription to JBoss Data Grid is long-term support and maintenance.
If you could explain in more detail what you are trying to achieve, we can help you much better.
Regards
Tristan