Dmitriy, I suppose I could do that (restart the cluster) but I suppose in that case I have to have a strategy to dump the cache contents somewhere and reconstruct it after startup. It's not always about changes to existing classes being cached, it is also about adding classes to cache - in this scenario I decide to cache more data and for that too I would have to restart the cluster after copying the jars around.
What does "zero deployment" actually mean (I saw this on the GridGain pages)? Does it also apply to Ignite? Thanks! On Mon, Apr 27, 2015 at 10:57 AM, Dmitriy Setrakyan <[email protected]> wrote: > Ognen, > > What kind of behavior do you need for the deployment? For example, if your > caches already have data with older classes, what should happen to that > data? > > Of course, the easiest way to accomplish what you are doing is to copy the > new jars everywhere and restart the cluster. If this approach is > acceptable, I would just go with it. > > D. > > On Sun, Apr 26, 2015 at 7:29 PM, Ognen Duzlevski < > [email protected]> > wrote: > > > I have a 5 machine ignite grid deployed on EC2 (still very much in > testing > > but would like to move to becoming more serious about using it in > research > > at least and eventually in production). In order to be able to cache > > various Scala/java classes, I created a fat jar of my Scala app and put > it > > in the ignite/libs/ subdirectory. Then I start ignite on each node by > > running the ignite.sh script. > > > > When I add new classes, I recompile the app and create a new fat jar. How > > does one deploy this new code so that the already running ignite becomes > > aware of it? I am not much of a Java programmer (jumped straight to > Scala) > > - are there any ways Java allows for loading new classes/jars "on the > fly" > > into running JVMs? If so, does Ignite support them? If not, what do > people > > do to deploy new jars so they can become usable to an already running > cache > > grid? > > > > Thanks! > > Ognen > > >
