[infinispan-dev] Distributed tasks - specifying task input

Manik Surtani manik at jboss.org
Fri Dec 17 09:01:25 EST 2010


On 17 Dec 2010, at 11:56, Vladimir Blagojevic wrote:

> On 10-12-17 8:42 AM, Manik Surtani wrote:
>> 
>> I was just wondering whether such a use case exists or whether we're 
>> just inventing stuff.  :-)  It would lead to a much more cumbersome 
>> API since you'd need to provide a map of cache names to keys, etc.
> 
> Ok agreed. Unless there is a way to solve this nicely lets go with cache 
> based DT. I'll think more about this over the weekend.

Hmm, just saw Sanne's message.  Ok, so if we were to support multiple caches... how could this look?

interface DistributedTask<K, V, R> {

   Collection<String> cacheNames();

   Collection<K> keys(String cache);

   void map(String cacheName, Map.Entry<K, V> e, DistributedTaskContext <K, V, R> ctx);

   R reduce(Map<Address, DistributedTaskContext<K, V, R>> contexts);

}

interface DistributedTaskContext<K, V, R> {
   
   String getCacheName();
  
   // ... map-like methods on K, V
}

DistributedForkJoinPool p = cacheManager.newDistributedForkJoinPool();

result = p.invoke(new DistributedTask() { ... });

and let the DistributedTask impl provide the names of caches and keys as needed?  Some semantics - a null collection of cache names = all caches, a null collection of keys = all keys?  Or is that a bit shit?  :-)

Cheers
Manik

> 
> Also, why would you call DT#map for each key specified? I am thinking it 
> should be called once when task is migrated to execution node, context 
> should be filled with entries on that cache node and passed to map. So 
> call map once per node with all keys already in context.

Just saves the implementation having to iterate over the collection.  We do the iterating and callback each time.  :-)  Minor point.

> I'd also try to use our own interfaces here rather than pure Map so we 
> can evolve them if we need to - DistributedTaskContext or whatever.....

+1.

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org






More information about the infinispan-dev mailing list