DIST.retrieveFromRemoteSource
by Sanne Grinovero
Hello,
in the method:
org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(Object,
InvocationContext, boolean)
we have:
List<Address> targets = locate(key);
// if any of the recipients has left the cluster since the
command was issued, just don't wait for its response
targets.retainAll(rpcManager.getTransport().getMembers());
But then then we use ResponseMode.WAIT_FOR_VALID_RESPONSE, which means
we're not going to wait for all responses anyway, and I think we might
assume to get a reply by a node which actually is in the cluster.
So the retainAll method is unneeded and can be removed? I'm wondering,
because it's not safe anyway, actually it seems very unlikely to me
that just between a locate(key) and the retainAll the view is being
changed, so not something we should be relying on anyway.
I'd rather assume that such a get method might be checked and
eventually dropped by the receiver.
Cheers,
Sanne
12 years, 11 months
again: "no physical address"
by Sanne Grinovero
Hi Bela,
this is the same error we where having in Boston when preparing the
Infinispan nodes for some of the demos. So I didn't see it for a long
time, but today it returned especially to add a special twist to my
performance tests.
Dan,
when this happened it looked like I had a deadlock: the benchmark is
not making any more progress, it looks like they are all waiting for
answers. JConsole didn't detect a deadlock, and unfortunately I'm not
having more logs than this from nor JGroups nor Infinispan (since it
was supposed to be a performance test!).
I'm attaching a threaddump in case it interests you, but I hope not:
this is a DIST test with 12 nodes (in the same VM from this dump). I
didn't have time to inspect it myself as I have to run, and I think
the interesting news here is with the "no physical address"
ideas?
[org.jboss.logging] Logging Provider: org.jboss.logging.Log4jLoggerProvider
[org.jgroups.protocols.UDP] sanne-55119: no physical address for
sanne-53650, dropping message
[org.jgroups.protocols.pbcast.GMS] JOIN(sanne-55119) sent to
sanne-53650 timed out (after 3000 ms), retrying
[org.jgroups.protocols.pbcast.GMS] sanne-55119 already present;
returning existing view [sanne-53650|5] [sanne-53650, sanne-49978,
sanne-27401, sanne-4741, sanne-29196, sanne-55119]
[org.jgroups.protocols.UDP] sanne-39563: no physical address for
sanne-53650, dropping message
[org.jgroups.protocols.pbcast.GMS] JOIN(sanne-39563) sent to
sanne-53650 timed out (after 3000 ms), retrying
[org.jgroups.protocols.pbcast.GMS] sanne-39563 already present;
returning existing view [sanne-53650|6] [sanne-53650, sanne-49978,
sanne-27401, sanne-4741, sanne-29196, sanne-55119, sanne-39563]
[org.jgroups.protocols.UDP] sanne-18071: no physical address for
sanne-39563, dropping message
[org.jgroups.protocols.UDP] sanne-18071: no physical address for
sanne-55119, dropping message
12 years, 11 months
Write skew doubt
by Pedro Ruivo
Hi,
I've noticed that in the last version (5.1.x) the write skew check is
performed on all keys written. However, from your documentation [1] I
understood that the write skew was meant to be performed only on the
written keys that were previously read.
Is this change intentional?
Cheers,
Pedro Ruivo
[1] https://docs.jboss.org/author/display/ISPN51/Data+Versioning
"Write skew checks are performed at prepare-time to ensure a concurrent
transaction hasn't modified an entry while it was read and potentially
updated based on the value read."
12 years, 11 months
