On Tue, Apr 28, 2015 at 06:02PM, Dmitriy Setrakyan wrote: > I agree, the concern is valid. > > Ognen, Cos, what do you think should be the right behavior? Should we allow > different versions of the objects live in the same cache? GridGain
Being able to have different versions of the objects might be a bliss (I'm not sure if that would fit Ognen usecase). But it might come with the funny situations such as when an older revision never got purged off a cache, causing potential data-conflicts, etc. To me peerClassLoading seems to fine, but users need to be aware about its effects. Just thinking out loud, really. Cos > enterprise edition, by the way, allows it with Portable Objects. > > If you would like to clear the older object versions and deploy new ones > automatically, Ignite supports it already. Just enable peerClassLoading on > Ignite configuration. > > D. > > On Tue, Apr 28, 2015 at 8:43 AM, Ognen Duzlevski <[email protected]> > wrote: > > > Cos, thanks. If anyone has any suggestions, I would be glad to hear them > > :-) > > > > On Tue, Apr 28, 2015 at 12:59 AM, Konstantin Boudnik <[email protected]> > > wrote: > > > > > I think Ognen has raised a very valid concern in [1]: what to do when you > > > have > > > a huge cluster? Esp. on multi-tenant systems you can not just bounce the > > > whole > > > thing on every application's DO classes change. Is it possible to do > > > rolling > > > restart of the cluster nodes, where some of the nodes will still be on > > the > > > old > > > version of the classes and some on the new one? > > > > > > Sorry for using the nabble link, but > > > mail-archives.apache.org/mod_mbox/ignite-dev takes forever to get > > updated. > > > > > > Cos > > > > > > [1] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/New-contributor-tp114p123.html > > > > > > On Mon, Apr 27, 2015 at 08:57AM, Dmitriy Setrakyan 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 > > > > > > > > > >
signature.asc
Description: Digital signature
