Support for Hazelcast 4.x

[lamodeo]

Is there plans to support Hazelcast 4.x with the current 20.0.0.x versions of Liberty? It appears the last version of Liberty tested was 16.0.0.3 from 3+ years ago using Hazeclast 3.x client code. Concerned with Liberty/Dynacache Plugin/Hazelcast version compatibility.

[mesutcelik]

We might release hazelcast 4 supported version based on demand in future.
What is your use case? Did you try to use Hazelcast API directly in your codebase instead of dyncache?
What is your tech stack?

[lamodeo]

Thanks for the fast response. My use case is my organization hosts a number of Liberty applications that use eXtremeScale. They use the DistributedMap, ObjectGrid API, and HTTP Session caching. Most use the DistributedMap and HttpSession functionality. Having the plugin should allow a transparent migration of the applications that use the DistributedMap functionality. The API is the least used approach and I will need to have the developers migrate to JCache API for that one buts its a small subset. We are always pretty current with Liberty within 3-4 months of the latest released version.

We are evaluating Hazelcast as an eXtremeScale replacement and availability of DistributedMap functionality is a key component.

[mesutcelik]

Thanks @lamodeo for the detailed answers. I have some more questions that are not clear to me.

Is this OpenLiberty or WAS Liberty profile?
Are you planning to use Hazelcast embedded or client/server?

Just to clarify, are these the migrations you intent to have?

1. eXtremeScale via Dynacache DistributedMap --> Hazelcast via Dynacache DistributedMap
2. ObjectGrid API --> Hazelcast via JCache
3. HttpSession with eXtremeScale --> Hazelcast via Liberty JCache Session Replication

For the #1, Do you have any plan to replace Dynacache DistributedMap by JCache if you are not planning to use Hazelcast API directly.

[lamodeo]

We use WAS Liberty Profile. We are a WAS shop that has been transitioning WAS apps to WAS Liberty. I am leaning toward client/server to keep the applications and grid servers separate for better isolation and maintainability. Not cast in stone though at this point.

#1 - Yes, We are hoping to seamlessly migrate to Hazelcast Distributed Map using existing Liberty Interfaces. My understanding is that WAS Liberty supports the notion of an alternative cache provider that allows JCache enabled providers to replace the caching engine and "plug-in" to the DistributedMap/Dynacache functionality transparently. This is what we are trying to exploit with Hazelcast. So lookup the DistributedMap via jndi access caching functionality using DistributedMap interface put/get etc. We currently do not have plans to move away from DistributedMap due to the number of different applications that exploit it. Since I personally have not developed this code and it involves several development teams within our organization its a huge effort to get folks to agree to change their applications to use the API.

#2 - Yes, We want to move to the JSR-107 standard for the apps that use the API.

#3 - Yes, We want to exploit HttpSession via JSR-107 JCache using Hazelcast as the provider.

We are trying to position ourselves to use JSR-107 exclusively and eliminate proprietary interfaces but I really cannot say how long this will take to accomplish this. The ability to migrate our legacy applications as seamless as possible is key.

Please let me know if you have any more questions. Thank You.

[scottpmc]

Hi @lamodeo - I'd like to document your needs for our engineering team. Priorities are driven by community requests and we're seeing an uptick in Liberty support requests, so we're looking at raising its priority. Please send an email to scottpmc@gmail.com and I will respond from Hazelcast email.

[andrey-yemelyanov]

Hi,

Our project would also like to request addition of support for Hazelcast 4.x. We are setting up a Hazelcast cluster inside Kubernetes. I have tried running release 0.3 of the Dynacache provider against Hazelcast 4.x and got an error: Unable to send packet to null. We then switched back to Hazelcast 3.12 and it worked like a charm.

Due to a large amount of code base already relying on Dynacache we are unable to use Hazelcast API programmatically in code.

[leszko]

As a matter of fact, we're currently not actively working on implementing the support for Hazelcast 4.x. Saying that we'd love to accept a PR from the community. So, if anyone is interested, please send a PR.