The various bulk operations for the Map interface are now implemented
to utilize the entire cluster in the new Infinispan 7.0 Release [1].
Please find more information about the bulk operations at [2]
[1] http://blog.infinispan.org/2014/11/infinispan-700final-is-out.html
[2]
On 10/13/2014 05:55 PM, Mircea Markus wrote:
On Oct 13, 2014, at 14:06, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 9:01 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 10, 2014, at 17:30, William Burns mudokon...@gmail.com wrote:
Also we didn't really talk about
On Tue, Oct 14, 2014 at 9:55 AM, Radim Vansa rva...@redhat.com wrote:
On 10/13/2014 05:55 PM, Mircea Markus wrote:
On Oct 13, 2014, at 14:06, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 9:01 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 10, 2014, at
On Tue, Oct 14, 2014 at 3:33 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Oct 14, 2014 at 9:55 AM, Radim Vansa rva...@redhat.com wrote:
On 10/13/2014 05:55 PM, Mircea Markus wrote:
On Oct 13, 2014, at 14:06, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at
On Fri, Oct 10, 2014 at 8:51 PM, Mircea Markus mmar...@redhat.com wrote:
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:
On Fri, Oct 10, 2014 at 9:01 PM, Mircea Markus mmar...@redhat.com wrote:
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
On Oct 13, 2014, at 14:06, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 9:01 PM, Mircea Markus mmar...@redhat.com wrote:
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
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
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() ? :-)
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 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
On Wed, Oct 8, 2014 at 7:53 PM, William Burns mudokon...@gmail.com wrote:
On Wed, Oct 8, 2014 at 12:41 PM, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 6:19 PM, Radim Vansa rva...@redhat.com wrote:
Users expect that size() will be constant-time (or linear to
On Oct 8, 2014, at 16:19, 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
On Oct 8, 2014, at 15:42, William Burns mudokon...@gmail.com wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
further out. I should be able to put this together for CR2.
+1, plese go for it.
On Oct 8, 2014, at 15:57, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 5:42 PM, William Burns mudokon...@gmail.com wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
further
On Oct 6, 2014, at 12:44, Tristan Tarrant ttarr...@redhat.com wrote:
I think we should provide correct implementations of size() (and others)
and provide shortcut implementations using our usual Flag API (e.g.
SKIP_REMOTE_LOOKUP).
for keySet and values, Will's distributed iteration is a
On Oct 8, 2014, at 15:11, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 5:03 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 3, 2014, at 9:30, Radim Vansa rva...@redhat.com wrote:
Hi,
recently we had a discussion about what size() returns, but I've
realized
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
further out. I should be able to put this together for CR2.
It seems that we want to implement keySet, values and entrySet methods
using the entry iterator
On Wed, Oct 8, 2014 at 5:42 PM, William Burns mudokon...@gmail.com wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
further out. I should be able to put this together for CR2.
I'm not 100%
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 mudokon...@gmail.com wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
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 mudokon...@gmail.com
wrote:
So it seems we would want to change this for 7.0 if possible
On Wed, Oct 8, 2014 at 12:41 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 6:19 PM, 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,
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum of cache.withFlags(SKIP_REMOTE_LOOKUP,
SKIP_BACKUP_ENTRIES).size() from all nodes? (note that there's no
SKIP_BACKUP_ENTRIES flag right now), where this method returns
localStore.size() for
On Tue, Oct 7, 2014 at 7:32 AM, Radim Vansa rva...@redhat.com wrote:
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum of cache.withFlags(SKIP_REMOTE_LOOKUP,
SKIP_BACKUP_ENTRIES).size() from all nodes? (note that there's no
On 10/07/2014 02:21 PM, William Burns wrote:
On Tue, Oct 7, 2014 at 7:32 AM, Radim Vansa rva...@redhat.com wrote:
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum of cache.withFlags(SKIP_REMOTE_LOOKUP,
SKIP_BACKUP_ENTRIES).size() from all
Considering all these very valid concerns I'd return on my proposal
for throwing runtime exceptions via an (optional) decorator.
I'd have such a decorator in place by default, so that we make it very
clear that - while you can remove it - the behaviour of such methods
is unusual and that a user
On Tue, Oct 7, 2014 at 8:43 AM, Radim Vansa rva...@redhat.com wrote:
On 10/07/2014 02:21 PM, William Burns wrote:
On Tue, Oct 7, 2014 at 7:32 AM, Radim Vansa rva...@redhat.com wrote:
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum of
Considering the frequency of How do I get the number of entries in
cache, How do I get all keys on all forums, I think that backing to
runtime exception would not satisfy the users.
On 10/07/2014 03:16 PM, Sanne Grinovero wrote:
Considering all these very valid concerns I'd return on my
I'm not sure idiot-proof API is what we want to encourage. I'd rather
tell users to RTFM.
Tristan
On 07/10/14 16:23, Sanne Grinovero wrote:
On 7 October 2014 14:42, Radim Vansa rva...@redhat.com wrote:
Considering the frequency of How do I get the number of entries in
cache, How do I get all
On 3 October 2014 18:38, Dennis Reed der...@redhat.com wrote:
Since size() is defined by the ConcurrentMap interface, it already has a
precisely defined meaning. The only correct implementation is E.
+1
The current non-correct implementation was just because it's expensive
to calculate
I think we should provide correct implementations of size() (and others)
and provide shortcut implementations using our usual Flag API (e.g.
SKIP_REMOTE_LOOKUP).
Tristan
On 06/10/14 12:57, Sanne Grinovero wrote:
On 3 October 2014 18:38, Dennis Reed der...@redhat.com wrote:
Since size() is
On 6 October 2014 12:44, Tristan Tarrant ttarr...@redhat.com wrote:
I think we should provide correct implementations of size() (and others)
and provide shortcut implementations using our usual Flag API (e.g.
SKIP_REMOTE_LOOKUP).
Right that would be very nice. Same for CacheStore interaction:
Hi,
recently we had a discussion about what size() returns, but I've
realized there are more things that users would like to know. My
question is whether you think that they would really appreciate it, or
whether it's just my QA point of view where I sometimes compute the
'checksums' of cache
Since size() is defined by the ConcurrentMap interface, it already has a
precisely defined meaning. The only correct implementation is E.
The current non-correct implementation was just because it's expensive
to calculate correctly. I'm not sure the current impl is really that
useful for
41 matches
Mail list logo
