Vladimir, from a HotRod protocol perspective we'd need a new operation but 
after that the body, as Manik suggested, you could have javascript which the 
HotRod server ignores and passes it to the distexec code which deals with it 
accordingly.

I was wondering too whether we'd need streaming here or not but at first glance 
it does not appear to be as important as in remote querying.

On May 4, 2011, at 11:51 PM, Manik Surtani wrote:

> Well, I feel exposing M/R over Hot Rod - from a protocol standpoint - would 
> require a platform-independent mechanism of defining a closure (keeping in 
> mind we need to allow this from non-Java clients too).
> 
> So I reckon Javascript is the way to go, at least from a protocol standpoint. 
>  Now how we expose this in remote client APIs (Java, Python, etc) needs some 
> thought, but at first glance it would seem as though we won't have a direct 
> mapping to what we do on the embedded side of things.  E.g., 
> http://www.mongodb.org/display/DOCS/MapReduce
> 
> - Manik
> 
> On 4 May 2011, at 04:50, Vladimir Blagojevic wrote:
> 
>> Galder,
>> 
>> I believe the ability to invoke distributed executors and mapreduce over 
>> hotrod would be very interesting. However, I quickly realized that 
>> internals of both DistributedExecutorService and MapReduceTask rely 
>> heavily on some Cache internals (RpcManager, CommandsFactory, 
>> InterceptoChain) that are only available in non-remote caches. There is 
>> no way to fake this by simply passing RemoteCache instead of Cache. 
>> Either we rethink the internals of DistributedExecutorService and 
>> MapReduceTask or we somehow bridge to these abstractions from a thin 
>> client.
>> 
>> Any thoughts how we could potentially achieve hotrodization of dist. exec?
>> 
>> Regards,
>> Vladimir
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to