users@shoal.java.net

Re: [Shoal-Users] Message serialization question

From: Michael Bien <mbien_at_fh-landshut.de>
Date: Tue, 30 Sep 2008 19:47:27 +0200

Olaf Krische wrote:
> Hello Jim,
>
>
> On Tue, Sep 30, 2008 at 09:38:05AM -0700, Jim Marino wrote:
>
>> I noticed in ClusterManager.send(final ID peerid, final Serializable
>> msg) messages are serialized using Java serialization. Since our
>> message classes will be loaded in a different classloaders than the
>> TCCL or the Shoal classloader, we need to insert a mechanism to handle
>> deserialization in our peer classloader environment. Currently, we
>> are using JXTA for communication and have implemented a mechanism to
>> handle serialization/deserialization in our environment. Is there a
>> way our runtime can hook into Shoal to perform message serialization/
>> deserialization? If not, would the best approach be to encode our
>>
>
> With Shoal you will always send messages as byte[]:
>
> GroupManagementService gms = ...;
> gms.getGroupHandle().sendMessage(..., byte[] message);
>
> And in reverse, you get byte[], wenn unpacking a message:
>
> String groupName = signal.getGroupName();
> String sender = signal.getMemberToken();
> if (signal instanceof MessageSignal) {
> MessageSignal messageSignal = (MessageSignal)signal;
> String targetComponent = messageSignal.getTargetComponent();
> byte[] message = messageSignal.getMessage()
> ...
> }
>
> So you can hook up your own serializer/deserializer.
>
> Hope it helps.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>

Hi,

i had almost the same problem in FishFarm i just called the solution
distributed-classloader instead of peer-classloader :-).

FishFarm has worker nodes which steal work from overstrained other nodes
executing computational expensive tasks (@see jsr166y). This means that
the overstrained node (currently executing the task) knows the resources
which are required from the idle node anyway (since he was already
executing the task...).

solution is obvious... ask friendly for resources if you need them after
stealing a task.

DistributableObject (ala plain old MarshalledObject, just simpler and
fancier):
https://fishfarm.dev.java.net/source/browse/fishfarm/trunk/FishFarm/src/net/java/fishfarm/DistributeableObject.java?rev=183&view=markup

GridResourceLoader:
https://fishfarm.dev.java.net/source/browse/fishfarm/trunk/FishFarm/src/net/java/fishfarm/GridResourceLoader.java?rev=183&view=markup

GridClassLoader:
https://fishfarm.dev.java.net/source/browse/fishfarm/trunk/FishFarm/src/net/java/fishfarm/lang/ExtendableClassloader.java?rev=183&view=markup

ResourceRequestHandler:
https://fishfarm.dev.java.net/source/browse/fishfarm/trunk/FishFarm/src/net/java/fishfarm/ResourceRequestHandler.java?rev=174&view=markup


usage:
register ResourceRequestHandler
wrap object in DistributableObject, serialize, send byte[],

receive byte[], deserialize
obj.get(gridclassloader).

done

keep in mind FishFarm is GPL+cp ex, i don't want that you get problems
with your employee... (refactor, rename it etc ;-) )

best regards,

michael

btw, fishfarm does not support resource versions with this technique...
simplicity first (since you mentioned OSGI)