Redeployment Strategy?

classic Classic list List threaded Threaded
2 messages Options
kevin kevin
Reply | Threaded
Open this post in threaded view
|

Redeployment Strategy?

This post has NOT been accepted by the mailing list yet.
Let's say I have made a code change to my application and I want to redeploy it. Is it possible to do so without taking down the entire Ignite cluster, in order to reduce service down time?
From what I've found so far, this does not seem possible, at least for all types of code change. Maybe some Ignite experts can chime in?
Eg. I have 5 nodes. I want to take down 1 node, update the jars, take it back up, then repeat for the other 4 nodes
The biggest problem I see is that if I changed the class of an object that's in the data grid cache (eg. added a field), when the node with the new code comes up, it won't be able to deserialize the existing objects in the data grid cache.
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

Re: Redeployment Strategy?

kevin wrote
Let's say I have made a code change to my application and I want to redeploy it. Is it possible to do so without taking down the entire Ignite cluster, in order to reduce service down time?
From what I've found so far, this does not seem possible, at least for all types of code change. Maybe some Ignite experts can chime in?
Eg. I have 5 nodes. I want to take down 1 node, update the jars, take it back up, then repeat for the other 4 nodes
The biggest problem I see is that if I changed the class of an object that's in the data grid cache (eg. added a field), when the node with the new code comes up, it won't be able to deserialize the existing objects in the data grid cache.
Hi Kevin,

1.4.0 which is expected next week will include new feature called 'portable objects': https://issues.apache.org/jira/browse/IGNITE-1258. It will allow not to have classes on server nodes and dynamically change data schema. Looks like it should solve your issue.

-Val