[infinispan-dev] New draft for distributed execution framework

Manik Surtani manik at jboss.org
Tue Nov 30 11:38:29 EST 2010


On 30 Nov 2010, at 12:56, 이희승 (Trustin Lee) wrote:

> On 11/30/2010 07:11 PM, Manik Surtani wrote:

<SNIP />

>> * Do we want to support this for replicated mode?  Typically, replicated clusters will be small and won't really benefit from task execution.  Maybe we add in support for replication later, if there is adequate demand?  It shouldn't change the API, etc.
> 
> For example, a user might want to run a cluster of 100 nodes with 2
> replicas just like Google File System does.  Why is such cluster
> supposed to be small?  Could you elaborate?

Ah, in Infinispan Replication refers to REPL mode, which means every node maintains a replica.  E.g., if you have 100 nodes, you have 100 copies of everything.

Distribution refers to using a Consistent Hash algorithm to maintain a fixed number of copies (e.g., 2) regardless of how big a cluster is (e.g., 100 nodes).  I see the F/J framework being useful here.

http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/config/Configuration.html#setCacheMode(java.lang.String)

>> * Could you define where each of these tasks are executed?  E.g., in a grid of {A, B, C, D} and you invoke your example on A, the local tasks happen on any node which contains the data it needs, while the global task happens on A?  Surely in many cases it makes sense to "reduce" before pushing results (final or intermediate) on the network?
> 
> Each node runs the first two sub-tasks and then one node is chosen to
> run the last one.  Timeline will look like this:
> 
>  A: Task1 .. Task2 ... Task3
>  B: Task1 .. Task2 /
>  C: Task1 .. Task2 /
>  D: Task1 .. Task2 /

Right, but this is specific to your example.  How would one specify what sort of characteristics they need from each task?

> 
> Because Task1 and 2 are executed in the same node, they could be done
> via a simple invocation chaining.  The transition from Task2 to Task3
> will involve network communication.  In the example, the output is only
> one entry, so it will be kept in memory until the node A's Task3 picks
> them up.  If Task2 generates a lot of entries, each node will hold them
> in memory and block the task execution on ctx.write() until the Task3
> picks them up.
> 
> One potential problem is when Node A fails while running Task3.  Because
> the intermediary entries are loaded into memory and lost as soon as they
> are consumed, there's no way to re-retrieve the intermediary output and
> the entire task needs to be re-run.  A user can simply split the task to
> two parts to store the intermediary output in the cache.
> 
>> * Non-Java language support - this should be out of scope for now, as it adds a layer of complexity we don't need.  We will certainly add support for map/reduce over Hot Rod in future, perhaps using JSON/JavaScript, but not for now.  :)
>> * Client/Server development: again, out of scope for now.  See above.  Once we have map/reduce over Hot Rod, client/server would be trivial.
> 
> Agreed.  I didn't mean to implement in 5.0 unless there is good deal of
> demand. :-)
> 
> More feed back appreciated in advanced, folks! :-)
> 
> -- 
> Trustin Lee, http://gleamynode.net/
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




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


More information about the infinispan-dev mailing list