[2005-03-06 04:49] Phillip Rhodes said:
| I'm working on a framework / libary for doing "distributed threads."
| That is, I want a subclass of Thread that spins the work off to
| a separate machine. Think of it as a way to do parallel programming
| in Java, where the library tries to look as much like normal
| java thread programming as possible.
Eh, this sounds interesting. Any particular application
in mind targeting the framework?
| > Are you exporting objects from
| > various machines onto a single/central registry?
|
| Yes. Given the nature of this thing, each of the machines that is part
| of the system needs to have an exported object running on it, but there
| needs to be a central place for the "thread manager" to go look
| to get a free node / thread. That's why rmiregistry won't really work
| for this. Well, not without layering another layer of gunk on top of it,
| anyway.
Strange that I ended up having to solve this same problem--allowing
a remote client to bind a Remote into the registry. Actually, as you
state, that can't be done directly, but I wrote my own registry
whose Registry methods used an ExecutorService to call the underlying
registry, getting around the non-local check of the Sun RegistryImpl
that my RegistryImpl extended. Quite a neat hack, methinks :-)
| I'm actually using the JBoss naming server right now, and it works OK.
| But in theory, now that I've worked out how to get to the stub object
| that can be serialized and passed around, any naming / directory system
| would work. I'll probably try to test it with OpenLDAP at some point,
| just for grins and giggles.
Ah, I see, you don't have a requirement for the Java RMI. I wish
I had the luxury of using an alternate RMI, because I wouldn't choose
the standard Java RMI. I'm now working on a way to gzip the RMI
messages, because in my RMI environment, there is about 1MB of
RMI chatter to render about 30k of actual data. So, that's this
weekend's project...
cheers!
Brent
_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org
