[infinispan-dev] Comments on latest iteration of Distributed Task Execution design

Vladimir Blagojevic vblagoje at redhat.com
Fri Jul 30 12:10:41 EDT 2010


On 2010-07-30, at 11:50 AM, Manik Surtani wrote:

> 
> On 30 Jul 2010, at 16:36, Vladimir Blagojevic wrote:
> 
>>> * Proposed interfaces - Not sure if I understand the purpose of DistributedCallable#mapped().  You already assign a cache to the callable in DistributedCallable#initialized(), right?
>> 
>> The intent of initialized call was to bootstrap task into environment at the master node, the node invoking the distribution of callables. The purpose of initialize is two fold. Task implementor can look up input that was given to it in constructor of DistributedCallable and interpret this input (e.g which keys to use, which particular cache etc etc) and in turn inform execution environment which cache it would use for data input so proper ConsistentHash can be passed in preferredExecutionNodes by the environment. I wanted to isolate task implementor from digging deep into Infinispan internals to figure out how to fulfill preferredExecutionNodes contract. preferredExecutionNodes is invoked while task is still at master node before migration to execution node.
> 
> Not sure I understand.  If you are passing in a reference to the cache the Callable is executed on (in mapped()) and you are passing in a ConsistentHash in preferredExecutionNodes(), what is the purpose of initialized()?  Why would a Callable need a reference to the Cache instance at the "master node", as you put it?


Sure, sure. I complicated it unnecessarily :) 

We might need only one callback on master node. But how do we do design it properly to accommodate the need of the task to do some task input interpretation using interaction with cache and return list of preferred execution nodes at the same time? 

How about just DistributedCallable#getRelatedKeys(EmbbededCacheManager cm)?




More information about the infinispan-dev mailing list