[infinispan-dev] Map Reduce 2.0

[Manik Surtani]

On 1 Jun 2012, at 16:21, Vladimir Blagojevic wrote:

> On 12-06-01 4:49 AM, Manik Surtani wrote:
>> 
>> We should update the interface then to indicate how you intend to make the ExecutorService made available to implementations.  :)
> 
> We can provide setDistributedExecutorService(DistributedExecutorService service) method on DistributedTaskFailoverPolicy interface? However, users can rather easily construct their own impl of DistributedTaskFailoverPolicy by passing instance of readily available DistributedExecutorService through a DistributedTaskFailoverPolicy constructor for example. The downside is that only programmatic configuration would work in this case. If we have set method contract then we can setup custom task failover through xml configuration. WDYT?

+1 to having a policy that can be configured via XML.

>>>> * Do you plan to include any canned failover policies?  If so, what are these?
>>> Yes, at least random and never failover policy.
>>>> * Shouldn't  DistributedTaskFailoverPolicy be parameterised to return the same type as DistributedFuture.get() rather than an untyped Object?
>>> I would love to make it but how can we do it? DefaultExecutorService is not typed and method of DistributedTaskFailoverPolicy is not either.
>> Can DTFP not be typed?  And even our sub-interface of ExecutorService?
>> 
> I am not sure if we should type our sub interface of ExecutorService. Although I do not know how to argue against it, all sub interfaces and impls I have seen use generic methods. Probably because generic methods give you more flexibility. So yes DTFP can by typed albeit not a very useful thing as DTFP should deal with generic type T rather than particular type. I think there is no need to type the interface when we can type method in DTFP. Also up until today I thought that generic method can infer its parameter type from its argument type only. However, even this works:
> 
> <T> T foo(){...}
> 
> Pretty cool! 

Do you have an example of what you are proposing by inferring its type?

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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120606/b8a6788d/attachment.html