Hi Radim,
I might misunderstand your suggestion but many M/R jobs actually require to run
the two phases one after the other, and henceforth to store the intermediate
results somewhere. While some may slightly reduce intermediate memory usage by
using a combiner function (e.g., the word-count
Hi Etienne
I was going to suggest using a combiner - the combiner would process the
mapper results from just one node, so you should need at most double the
memory on that node. I guess we could reduce the memory requirements even
more if the combiner could run concurrently with the mapper...
On 12 February 2014 10:40, Mircea Markus mmar...@redhat.com wrote:
Hey Will,
With the current design, during a topology change, an event might be
delivered twice to a cluster listener. I think we might be able to identify
such situations (a node becomes a key owner as a result of the
Hi Sanne,
As Evangelos pointed out in London, it is not possible to run a mapper and a
combiner concurrently in the general case (there are exceptions where the
combiner can run on the stream of tuples generated by the Mapper).
The proposal to tighter integrate with Hadoop would make sense
On 30 Jan 2014, at 20:51, Mircea Markus mmar...@redhat.com wrote:
On Jan 30, 2014, at 9:42 AM, Galder Zamarreño gal...@redhat.com wrote:
On Jan 21, 2014, at 11:52 PM, Mircea Markus mmar...@redhat.com wrote:
On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard emman...@hibernate.org
On 05 Feb 2014, at 17:30, Emmanuel Bernard emman...@hibernate.org wrote:
On Wed 2014-02-05 15:53, Mircea Markus wrote:
On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard emman...@hibernate.org wrote:
Sure searching for any cache is useful. What I was advocating is that if
you search for more
On Mon, Feb 17, 2014 at 7:53 AM, Sanne Grinovero sa...@infinispan.org wrote:
On 12 February 2014 10:40, Mircea Markus mmar...@redhat.com wrote:
Hey Will,
With the current design, during a topology change, an event might be
delivered twice to a cluster listener. I think we might be able to
On Mon 2014-02-17 18:43, Galder Zamarreño wrote:
On 05 Feb 2014, at 17:30, Emmanuel Bernard emman...@hibernate.org wrote:
On Wed 2014-02-05 15:53, Mircea Markus wrote:
On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard emman...@hibernate.org
wrote:
Sure searching for any cache is
On 31 Jan 2014, at 09:28, Emmanuel Bernard emman...@hibernate.org wrote:
On 30 janv. 2014, at 20:51, Mircea Markus mmar...@redhat.com wrote:
On Jan 30, 2014, at 9:42 AM, Galder Zamarreño gal...@redhat.com wrote:
On Jan 21, 2014, at 11:52 PM, Mircea Markus mmar...@redhat.com wrote:
Hi Tristan,
We are still waiting for an OpenHFT HugeCollections update before we start
key stroking its adaption as an Off-Heap Impl of javax.cache.Cache (via
ISPN DataContainer API bridge). We envision our openHFT--ISPN adaptation
effort to look something like the attached slide.
By the way, Mircea, Sanne and I had quite a long discussion about this one and
the idea of one cache per entity. It turns out that the right (as in easy)
solution does involve a higher level programming model like OGM provides. You
can simulate it yourself using the Infinispan APIs but it is
11 matches
Mail list logo
