Ognen, There is no a simple answer to this question, but what you talk about is still possible.
1. You should care about data compatibility. So, you need to store data in the format that can be read by different app version - json; byte array with custom serialize/deserialize logic; your custom Marshaller implementation; or switching to JdkMarshalling that uses standard java serialization and therefore support mutations. 2. App logic compatibility - your logic and services belonging to compatible versions of the application should not break each other. I.e. different nodes of the cluster can carry different versions of the app. If node with newer version (client or server) initiates some operation on the cache it can bring all the data locally change it and save to cache OR send a job of a prev version to remote node. Then you can update your app restarting Ignite nodes one by one. After update is complete and all nodes carry same app version you can use any flow. Please note that Ignite currently does not support hot Ignite version upgrade. This is supported by GridGain. GridGain also has portable marshaler eliminating data compatibility issues. --Yakov 2015-05-27 18:46 GMT+03:00 Ognen Duzlevski <ognen.duzlev...@gmail.com>: > Hello all, > > I would like to re-raise this issue and see if anyone has any > production-grade recommendations for deploying new app versions to an > ignite cache. Basically the issue is this: you have a new version of an app > with new/changed classes that you would like cached. One way to deploy this > is to copy a fat jar to ignite/lib and restart ignite. However, this gets > to be pretty ornery as the real steps are dump cache, restart ignite with > new fat jar, reload cache, deploy app. On a large cluster this becomes > somewhat of an issue. > > Anyone have any recommendations or procedures they are following or > anything that they are using of the Ignite functionality that I have > missed? > > Thanks! > Ognen >
