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 <
[hidden email]>:
> 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
>
Locked
