GridGain does mobile code.
And it looks a wee bit more approachable than PreferredClassLoader.
Subscribe to:
Post Comments (Atom)
Mike Herrick's Blog.
Portland, Oregon (Credit: PDX Visitors Association)
Twitter Updates
Lijit Search
Blog Archive
-
▼
2007
(185)
-
▼
May
(29)
- The other shoe drops - And then there was light.
- XML Code Gen & Service Description Langauge
- Google GData
- LINA - now that is what I'm talkn' about!
- WADL Gateway Drug
- Lift on Scala & the Functional JVM
- Cyclocross Forest Park
- Large Application Architecture vs. Integration Arc...
- Fried Cheese Curds
- OR - Not
- Signs of Life @ Apache River
- Strategic Inflection Point
- OSS Middleware License Sort
- WS-LastYear
- Overheard in Portland
- Many Flavors of Grid Computing
- Mobile Code
- MSFT Patent Links
- $10MM for Spring
- Emerging from the Google OSS Grid Haze
- GridGain
- Spring is everywhere
- Grid & the Web vs. JavaSpaces
- Portland, Oregon == Weird
- Nice
- The Challenges of Latency
- Ahem Where are the Jini/JavaSpaces Bits?
- Angry Pilgrim
- Patents - OSS
-
▼
May
(29)
LibraryThing
Blog Roll
- Bill de hÓra
- Brenda Michelson
- Buko Obele
- Cameron Purdy
- Dan Creswell
- Dan Diephouse
- Erik Onnen
- Jack van Hoof
- James Snell
- Joel Spolsky
- Kris Tuttle
- Mark Baker
- markg
- Matt Asay
- Matt Raible
- Mike Dierken
- Mommydays
- Nikita Ivanov
- Patrick Logan
- Pete Lacey
- Reg Braithwaite
- Sam Ruby
- Sarge Dodge
- Simon Phipps
- Stefan Tilkov
- Steve Loughran
- Tim Bray
8 comments:
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