Mike Herrick's Blog.
GridGain does mobile code.
And it looks a wee bit more approachable than PreferredClassLoader.
Preferred class loading isn't that complicated. Any grid could benefit from that where a task's jar has a main or initial task definitions and a set of preferred classes to use internal to the task that should never conflict with anything the grid node's vm already knows about.
re: your next post, a preferred class loader is probably most useful for utility grids where the grid provider is unfamiliar with the task provider.But even computational grids would benefit from this kind of isolation of dependencies of various tasks.Hey, don't throw the baby out with the bath water! :-)
I'm just saying, it took you finding a Sun research paper and several days of booya to grok it. That's what I mean re: approachable. GridGain on the other hand has the benefit of being new. It has 1 web site and 1 wiki and 1 page that tells you about it.But you are right - it works - not sure if GridGain approach is as sophisticated. But perhaps it is good enough. Less might be more.You raise a good point - I should be cautious about throwing out the baby with the bath water. The truth is Jini/JavaSpaces has opened my mind to several things that I didn't understand before working with it. Now these things are very important to me in finding an alternative while watching Apache River and hoping someday it goes somewhere.
One comment: Apart from conventional per class loading (loading a class from the nearest node that has its definition) we support automatic hot-redeploymenty - and that's a main feature.Now, that's not trivial, but it enables a great development model where you... do no deployment what-so-ever. You just code in Eclipse/IDEA/NetBeans or vi and run your code as if you would run it without any grid - and all your latest changes (to the bytecode) get picked up onto the grid. Watch the screencast on the website for the demo of it...
Cool Nikita ... what things do you have to look out for? What if a task/job is being executed and bits change? Or doesn't that happen?
In brief, all grid tasks in GridGain are versioned (user version + internal system version). If user (re)deploys the same task (same ID and version) we detect if it has new bytecode and propagate it on the grid (using on-demand class loading).
So nikita, when you say "detect if it has new bytecode and propagate it on the grid (using on-demand class loading)", what happens when this detection happens and there are in-flight tasks and multiple threads have class loaders with the old code? Does the existing code simply get yanked out from under the job instance and the job replayed? Or, are jobs allowed to run to completion before the propagation happens and the new bytecode is laid down?
In short, when task gets (re)deployed it always gets the new class loader so that GridGain can happily run as many versions of the "same" task as needed.In your case, redeployment of already running task will not affect the already executing task (since they will be in different class loaders).
Post a Comment