[infinispan-dev] distributed execution - invoking commands on self

Vladimir Blagojevic vblagoje at redhat.com
Mon Apr 11 14:58:37 EDT 2011


Sanne,

I thought about that as well but I do not see a way to ensure that all 
other commands have been sent to other nodes other than waiting for 
corresponding futures to return from get and then invoke locally in a 
serial fashion.

I do not see a hook anywhere that will tell me when a command has been 
dropped on the wire!

Vladimir


On 11-04-11 2:21 PM, Sanne Grinovero wrote:
> 2011/4/11 Vladimir Blagojevic<vblagoje at redhat.com>:
>> Hi,
>>
>> I discovered a problem with distributed framework in cases where
>> Callables submitted for distributed execution contain mutable instance
>> fields. Just before Callable is dispersed across cluster it gets invoked
>> locally where instance fields of a submitted Callable can be possibly
>> mutated; Callable is in turn sent to remote nodes with mutated values
>> instead of "original" field values as submitted by user. For example,
>> consider pi approximation example from wiki [1]. If CircleTest Callable
>> declared insideCircleCount as an instance field instead of local field
>> of call method we would ultimately get a wrong final result.
>>
>> Therefore we need to ensure that each Infinispan node gets an unmodified
>> instance of Callable for execution. I was looking at the possibility to
>> send command to self thus causing creation of a marshaled copy of a
>> Callable, pretty much like any other remote node receives it. However, I
>> was unable to invoke a command on self. Any way to do this? How about
>> invoking marshaling locally to create a Callable copy without going
>> through rpc invocation layer? I though about skipping master/self node
>> altogether but that's an easy way out;-)
>>
>> Got suggestions, ideas?
> Hi Vladimir,
> I've no clue about invoking a marshalled command on self, but could
> you not just make sure the local callable is being processed *after*
> you have created a serialized copy (sent it to others) ?
>



More information about the infinispan-dev mailing list