Hi Sanne
On Wed, Jan 25, 2012 at 1:22 AM, Sanne Grinovero sa...@infinispan.org wrote:
Hello,
in the method:
org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(Object,
InvocationContext, boolean)
we have:
ListAddress targets = locate(key);
// if any of
On 1/25/12 9:51 AM, Dan Berindei wrote:
Slightly related, I wonder if Manik's comment is still true:
if at all possible, try not to use JGroups' ANYCAST for now.
Multiple (parallel) UNICASTs are much faster.)
Intuitively it shouldn't be true, unicasts+FutureCollator do basically
the
On 25 Jan 2012, at 08:51, Dan Berindei wrote:
Hi Sanne
On Wed, Jan 25, 2012 at 1:22 AM, Sanne Grinovero sa...@infinispan.org wrote:
Hello,
in the method:
org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(Object,
InvocationContext, boolean)
we have:
On 25 Jan 2012, at 09:42, Bela Ban wrote:
On 1/25/12 9:51 AM, Dan Berindei wrote:
Slightly related, I wonder if Manik's comment is still true:
if at all possible, try not to use JGroups' ANYCAST for now.
Multiple (parallel) UNICASTs are much faster.)
Intuitively it shouldn't
On 1/25/12 12:58 PM, Mircea Markus wrote:
On 25 Jan 2012, at 09:42, Bela Ban wrote:
On 1/25/12 9:51 AM, Dan Berindei wrote:
Slightly related, I wonder if Manik's comment is still true:
if at all possible, try not to use JGroups' ANYCAST for now.
Multiple (parallel) UNICASTs are
On 25 January 2012 11:48, Mircea Markus mircea.mar...@jboss.com wrote:
On 25 Jan 2012, at 08:51, Dan Berindei wrote:
Hi Sanne
On Wed, Jan 25, 2012 at 1:22 AM, Sanne Grinovero sa...@infinispan.org
wrote:
Hello,
in the method:
On 25 Jan 2012, at 12:06, Bela Ban wrote:
On 1/25/12 12:58 PM, Mircea Markus wrote:
On 25 Jan 2012, at 09:42, Bela Ban wrote:
On 1/25/12 9:51 AM, Dan Berindei wrote:
Slightly related, I wonder if Manik's comment is still true:
if at all possible, try not to use JGroups'
On 25 Jan 2012, at 12:06, Sanne Grinovero wrote:
On 25 January 2012 11:48, Mircea Markus mircea.mar...@jboss.com wrote:
On 25 Jan 2012, at 08:51, Dan Berindei wrote:
Hi Sanne
On Wed, Jan 25, 2012 at 1:22 AM, Sanne Grinovero sa...@infinispan.org
wrote:
Hello,
in the method:
[cut]
I agree, we should not ask all replicas for the same information.
Asking only one is the opposite though: I think this should be a
configuration option to ask for any value between (1 and numOwner).
That's because I understand it might be beneficial to ask to more than
one node
On 25 Jan 2012, at 13:25, Sanne Grinovero wrote:
[cut]
I agree, we should not ask all replicas for the same information.
Asking only one is the opposite though: I think this should be a
configuration option to ask for any value between (1 and numOwner).
That's because I understand it might
On 25 January 2012 13:41, Mircea Markus mircea.mar...@jboss.com wrote:
On 25 Jan 2012, at 13:25, Sanne Grinovero wrote:
[cut]
I agree, we should not ask all replicas for the same information.
Asking only one is the opposite though: I think this should be a
configuration option to ask for
One node might be busy doing GC and stay unresponsive for a whole
second or longer, another one might be actually crashed and you didn't
know that yet, these are unlikely but possible.
All these are possible but I would rather consider them as exceptional
situations, possibly handled by a
On 25 Jan 2012, at 17:09, Dan Berindei wrote:
On Wed, Jan 25, 2012 at 4:22 PM, Mircea Markus mircea.mar...@jboss.com
wrote:
One node might be busy doing GC and stay unresponsive for a whole
second or longer, another one might be actually crashed and you didn't
know that yet, these
On 25 January 2012 17:09, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Jan 25, 2012 at 4:22 PM, Mircea Markus mircea.mar...@jboss.com
wrote:
One node might be busy doing GC and stay unresponsive for a whole
second or longer, another one might be actually crashed and you didn't
know
14 matches
Mail list logo
