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
Hi Galder,
Did you have time to review the report, any feedback ?
Rgds,Rory
On 24/09/2014 09:21, Rory O'Donnell Oracle, Dublin Ireland wrote:
Below is a text output of the report for infinispan-6.0.2.
Rgds,Rory
JDK
Hi Rory
Galder is on PTO for another week, so I'll try to answer instead.
We only use sun.misc.Unsafe directly, in order to implement a variation of
Doug Lea's ConcurrentHashMapV8 that accepts a custom Equivalence
(implementation of equality/hashCode). I guess we'll have to switch to
Hi Dan,
Thank you for the feedback.
Rgds,Rory
On 10/10/2014 12:37, Dan Berindei wrote:
Hi Rory
Galder is on PTO for another week, so I'll try to answer instead.
We only use sun.misc.Unsafe directly, in order to implement a
variation of Doug Lea's ConcurrentHashMapV8 that accepts a custom
On Wed, Oct 8, 2014 at 11:19 AM, Radim Vansa rva...@redhat.com wrote:
Users expect that size() will be constant-time (or linear to cluster
size), and generally fast operation. I'd prefer to keep it that way.
Though, even the MR way (used for HotRod size() now) needs to crawl
through all the
Markdown chewed on my markup :)
https://raw.githubusercontent.com/tristantarrant/infinispan-playground-hybrid/master/README.md
On 10/10/14 15:42, Kurt T Stam wrote:
Hi Tristan,
I'm trying to follow your instructions but am I bit confused by the
following:
You will also need to modify the
On 10/10/2014 02:38 PM, William Burns wrote:
On Wed, Oct 8, 2014 at 11:19 AM, Radim Vansa rva...@redhat.com wrote:
Users expect that size() will be constant-time (or linear to cluster
size), and generally fast operation. I'd prefer to keep it that way.
Though, even the MR way (used for HotRod
What's wrong with sum(Datacontainer.size())/numOwners ?
Tristan
On 10/10/14 16:03, Radim Vansa wrote:
On 10/10/2014 02:38 PM, William Burns wrote:
On Wed, Oct 8, 2014 at 11:19 AM, Radim Vansa rva...@redhat.com wrote:
Users expect that size() will be constant-time (or linear to cluster
size),
That we should expose that as one method, not forcing people to
implement the sum() themselves.
And possibly cachestores, again.
Radim
On 10/10/2014 04:06 PM, Tristan Tarrant wrote:
What's wrong with sum(Datacontainer.size())/numOwners ?
Tristan
On 10/10/14 16:03, Radim Vansa wrote:
On
Exactly, in a monitoring application you wouldn't need the exact number of
key-value mappings in the cache.
The number of entries in memory and/or on disk should be much more
interesting, and we wouldn't have to worry about duplicated/missing/expired
entries to show that.
On Fri, Oct 10, 2014
On Fri, Oct 10, 2014 at 5:20 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 10, 2014, at 15:18, Radim Vansa rva...@redhat.com wrote:
That we should expose that as one method, not forcing people to
implement the sum() themselves.
Hmm, isn't the method you mention cache.size() ? :-)
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,
I meant as a quick implementation of that, not that we want to tell
users to do it.
Tristan
On 10/10/14 16:18, Radim Vansa wrote:
That we should expose that as one method, not forcing people to
implement the sum() themselves.
And possibly cachestores, again.
Radim
On 10/10/2014 04:06
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
On Wed, Oct 8, 2014 at 12:23 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 6:14 PM, William Burns mudokon...@gmail.com wrote:
On Wed, Oct 8, 2014 at 10:57 AM, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 5:42 PM, William Burns
On Oct 10, 2014, at 15:25, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 5:20 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 10, 2014, at 15:18, Radim Vansa rva...@redhat.com wrote:
That we should expose that as one method, not forcing people to
implement the
On Oct 10, 2014, at 16:22, Tristan Tarrant ttarr...@redhat.com wrote:
I meant as a quick implementation of that, not that we want to tell
users to do it.
+1. That would be accurate enough for practical reasons.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
On Oct 10, 2014, at 17:30, William Burns mudokon...@gmail.com wrote:
Also we didn't really talk about the fact that these methods would
ignore ongoing transactions and if that is a concern or not.
It might be a concern for the Hibernate 2LC impl, it was their TCK that
prompted the last
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
All,
I occasionally have to hard-reset my whole workspace, delete the
Eclipse projects, and re-import them, especially when I switch between
branches.
I have lots of projects, and they are all nicely grouped as Eclipse
shows projects in alphabetical order, and all projects use a
consistent
20 matches
Mail list logo
