leszko
commented
3 years ago I think it's really related to Kubernetes, but more to the Hazelcast cluster which consists of old/new members. Could you please create the GH Issue with the detailed steps to reproduce in https://github.com/hazelcast/hazelcast?
Also, you can use StackOverflow or Hazelcast Google Groups for such questions.
Closing.
I'm not sure this is a question to hazelcast-kubernetes, or more a general hazelcast topic, but the problem we're having might be just more visible when using hazelcast-kubernetes.
We use this distributed cache embedded into our springboot application. So we have finally multiple pods of the same application synchronising the cache between them.
When we do deploy a new application version, we leverage on kubernetes deployment rollout, so new pods are being created, and old ones are progressively removed as new ones are accepting requests. Meanwhile, cache gets synchronized between the pods (a mix of old pods and new pods).
The problem comes whenever there are changes on objects, that we start hitting serialization exceptions, impacting directly our customers, and so the only option we have to overcome this is to have an actual downtime, avoiding that these old objects versions cached try to get deserialized in our new application version, or the other way around.
I know there are some options such as providing custom Portable serialization, but we will be just fine just starting over a fresh cache in every new deployment.
Is there any easy way to manage the deployment of new versions, with zero downtime, and avoiding these serializations issues? We are just fine starting with no objects cached in a new deployment.
(i.e., maybe customizing cache name would do the trick, using the version? )
Thanks a lot in advance.