I am really sorry for the ridiculously late response. I will describe
briefly our 1st year and our current approach.
1st year approach.
During the first year, we used infinispan MR to implement our operators.
Most of our operators were Map-only (for example project,filter) and for
these we did
On Fri, Oct 10, 2014 at 6:49 PM, Emmanuel Bernard emman...@hibernate.org
wrote:
When wrestling with the subject, here is what I had in mind.
The M/R coordinator node sends the M task per segment on the node where
the segment is primary.
What's M? Is it just a shorthand for map, or is it a
On Fri, Oct 10, 2014 at 12:16 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 10/09/2014 04:41 PM, Dan Berindei wrote:
On Thu, Oct 9, 2014 at 3:40 PM, William Burns mudokon...@gmail.com
mailto:mudokon...@gmail.com wrote:
Actually this was something I was hoping to get to
On 2014-10-10, 3:03 AM, Dan Berindei wrote:
The problem is that the intermediate keys aren't in the same segment:
we want the reduce phase to access only keys local to the reducing
node, and keys in different input segments can yield values for the
same intermediate key. So like you say,
On Fri, Oct 10, 2014 at 6:13 PM, Vladimir Blagojevic vblag...@redhat.com
wrote:
On 2014-10-10, 3:03 AM, Dan Berindei wrote:
The problem is that the intermediate keys aren't in the same segment:
we want the reduce phase to access only keys local to the reducing
node, and keys in different
When wrestling with the subject, here is what I had in mind.
The M/R coordinator node sends the M task per segment on the node where
the segment is primary.
Each per-segment M task is executed and is offered the way to push
intermediary results in a temp cache.
The intermediary results are stored
Pedro and I have been having discussions with the LEADS guys on their
experience of Map / Reduce especially around stability during topology changes.
This ties to the .size() thread you guys have been exchanging on (I only could
read it partially).
On the requirements, theirs is pretty
Actually this was something I was hoping to get to possibly in the near future.
I already have to do https://issues.jboss.org/browse/ISPN-4358 which
will require rewriting parts of the distributed entry iterator. In
doing so I was planning on breaking this out to a more generic
framework where
On Thu, Oct 9, 2014 at 3:40 PM, William Burns mudokon...@gmail.com wrote:
Actually this was something I was hoping to get to possibly in the near
future.
I already have to do https://issues.jboss.org/browse/ISPN-4358 which
will require rewriting parts of the distributed entry iterator. In
On 10/09/2014 03:40 PM, William Burns wrote:
Actually this was something I was hoping to get to possibly in the near
future.
I already have to do https://issues.jboss.org/browse/ISPN-4358 which
will require rewriting parts of the distributed entry iterator. In
doing so I was planning on
On 10/09/2014 04:41 PM, Dan Berindei wrote:
On Thu, Oct 9, 2014 at 3:40 PM, William Burns mudokon...@gmail.com
mailto:mudokon...@gmail.com wrote:
Actually this was something I was hoping to get to possibly in the
near future.
I already have to do
11 matches
Mail list logo
