Re: [infinispan-dev] Map Reduce 2.0
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?
>> * 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!
Regards,
Vladimir
Attachments:
- attachment.html (text/html — 3.8 KB)