On 15 Dec 2010, at 18:43, Vladimir Blagojevic wrote:
On 10-12-15 3:03 PM, Manik Surtani wrote:
>
> I'm gonna cc infinispan-dev as well, so others can pitch in.
>
> But yeah, good start. I think your dissection of the use cases makes sense, except
that I think (a) and (c) are essentially the same; only that in the case of (c) the task
ignores any data input. This would raise the question of why would anybody do this, and
what purpose does it solve. :-) So yeah, we could support it as a part of (a), but I am
less than convinced of its value.
Ok, no problem. We just have to somehow bootstrap EntryStreamProcessorContext with no
access to cache for c case.
Well, I reckon we provide the ref to the cache. If the impl doesn't make use of it,
too bad.
> And as for data locality, perhaps this would work: don't define the necessary
keys in the Task, but instead provide these when submitting the task. E.g.,
>
> CacheManager.submitTask(task); // task goes everywhere, and receives an input
Iterator of all local entries on each node.
> CacheManager.submitTask(task, K...); // task goes to certain nodes that contain some
or all of K. Receives an input Iterator of all local entries on each node.
>
> WDYT?
Yes, I agree except I'd rather not submit task using CacheManager API. I'd rather
just obtain DistributedTask through CacheManager and use task#execute. That we we do not
overpollute CacheManager API.
CacheManager cm = ...;
DistributedTask task = cm.newDistributedTask(...);
task.execute();
task.execute(K...);
+1.
Ok, if we agree on this what else remains to be resolved? What did
you have in mind for further discussion?
Just to finalise the API. Would this be specific to a cache or a cache manager? E.g.,
should it be Cache.newDistributedTask()?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org