Thanks for this reply, Mircea.
Very interesting approach. By dispatching a distributed executor back to
the node (node 0) that produced the pinned key affinity for the object's
natural key, we could indeed do an iterative search (from node 2) to find
the original 'myObject' in the pinned cache
Ben, I'm pretty sure it's not possible to define getKeyForAddress as
returning the same type as its input key.
Let's say f1(address)(x) = getKeyForAddress(address, x)
f1(address) has to be injective for each address. So if the size of the key
domain is size(K) and the number of addresses is N,
/It's probably possible to define something like this instead:
PinnedKeyK getKeyForAddress(address, key)
/
This is fine. Do it this way.
/Even so, keeping the result key pinned to the same address after a
rebalance would be tricky - probably requiring some changes to the
ConsistentHash
Sent from my iPhone
On 14 Jun 2013, at 13:43, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Thanks for this reply, Mircea.
Very interesting approach. By dispatching a distributed executor back to
the node (node 0) that produced the pinned key affinity for the object's
natural key, we
/ Another thing you can do is have a replicated Cache holding the mapping
between the actual keys and the affinity keys./
Yes, no doubt about it. This will work.
But, it technically requires the additional participation of a second
full-blown Cache. It will work, but it is not gorgeous.
Sent from my iPhone
On 14 Jun 2013, at 19:14, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/ Another thing you can do is have a replicated Cache holding the mapping
between the actual keys and the affinity keys./
Yes, no doubt about it. This will work.
But, it technically
/ Can you leave with this limitations? /
Yes.
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027407.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
Sent from my iPhone
On 14 Jun 2013, at 19:39, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/ Can you leave with this limitations? /
Yes.
Just to reiterate, your *never* expects a node to crash?
--
View this message in context:
/
Just to reiterate, your *never* expects a node to crash? /
Easy now, Mircea!
All of us in the distributed computing community know that we live in a
world of necessary compromises (i.e. Brewer's CAP theorem, etc.) re: limits
of service guarantees and capabilities.
Now, of course, I do
On Fri, Jun 14, 2013 at 5:46 PM, cotton-ben
ben.cot...@alumni.rutgers.eduwrote:
/It's probably possible to define something like this instead:
PinnedKeyK getKeyForAddress(address, key)
/
This is fine. Do it this way.
/Even so, keeping the result key pinned to the same address after a
To be honest, Dan, your last post leaves me slightly concerned.
/
Just to be clear, KAS doesn't really allow you to pin a key to a certain
node. It only gives you a key that maps to the given node the moment you
called KAS.getKeyForAddress(Address) - by the time you call cache.put()
with
Sent from my iPhone
On 14 Jun 2013, at 20:08, Dan Berindei dan.berin...@gmail.com wrote:
Just to be clear, KAS doesn't really allow you to pin a key to a certain
node. It only gives you a key that maps to the given node the moment you
called KAS.getKeyForAddress(Address) - by the time you
so, in the event that no topology change takes place, may I otherwise
consider this key2node association /reliable/?
Mircea Markus-2 wrote
Sent from my iPhone
On 14 Jun 2013, at 20:08, Dan Berindei lt;
dan.berindei@
gt; wrote:
Just to be clear, KAS doesn't really allow you to pin a
Sent from my iPhone
On 14 Jun 2013, at 20:54, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
so, in the event that no topology change takes place, may I otherwise
consider this key2node association /reliable/?
Yes
___
infinispan-dev mailing list
Sent from my iPhone
On 14 Jun 2013, at 20:02, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/
Just to reiterate, your *never* expects a node to crash? /
Easy now, Mircea!
All of us in the distributed computing community know
I'm just trying to help Ben.
that we live in a
world
I'm just trying to help Ben.
Absolutely you are. And you are succeeding. Greatly appreciated, thank
you.
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027416.html
Sent from the Infinispan
Want to point out that without this signature added to the API
*K getKeyForAddress(Address address, K otherKey); * /*compute address
specific version of otherKey*/
we are finding the KeyAffinityService unusable. It is impossible for a
node, that is not the same as the node that produced
On 13 Jun 2013, at 17:11, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Want to point out that without this signature added to the API
*K getKeyForAddress(Address address, K otherKey); * /*compute address
specific version of otherKey*/
I might have misunderstood something, but do
We need a way for a foreign node to be able to come up with the same
affinityKey produced earlier by a local node.
Thanks for the response, Mircea. Let me elaborate.
E.g. consider the infinispan quick start that is made up of
AbstractNode.java, Node0.java, Node1.java, Node2.java
Let's say
Sent from my iPhone
On 13 Jun 2013, at 17:45, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
We need a way for a foreign node to be able to come up with the same
affinityKey produced earlier by a local node.
Thanks for the response, Mircea. Let me elaborate.
E.g. consider the
Hi,
First, nice work on org.infinispan.affinity.KeyAffinityService ... May I
make 2 recommendations.
1. Add to the interface an overload =
*K getKeyForAddress(Address address, K otherKey);/*compute
address specific version of otherKey*/*
2. Provide documentation that
On 16 May 2013, at 19:12, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Hi,
First, nice work on org.infinispan.affinity.KeyAffinityService ... May I
make 2 recommendations.
Thanks for the feedback!
1. Add to the interface an overload =
*K getKeyForAddress(Address
On 16 May 2013, at 19:12, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
2. Provide documentation that *explicitly* motivates users to
understand/exercise the differences (and compatibilities) of the
KeyAffinityService API and the Grouping API. Now, that I have some
competency using
Done. see https://issues.jboss.org/browse/ISPN-3112
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027155.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
Added to the FAQ:
https://docs.jboss.org/author/display/ISPN/Grouping+API+vs+Key+Affinity+Service
Excellent. Thanks.
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027156.html
Sent from the
thank you.
On 16 May 2013, at 20:00, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Done. see https://issues.jboss.org/browse/ISPN-3112
--
View this message in context:
Hi Infinispan-DEV team,
Could anyone provide pointers to Infinispan API sample code that could
assist us w/ our ambition to start building the attached distributed grid
use-case?
Any wiki how-to (or full code samples) would be especially helpful.
Specifically, how to use
KeyAffinityService,
On 8 May 2013, at 18:11, cotton-ben wrote:
Hi Infinispan-DEV team,
Could anyone provide pointers to Infinispan API sample code that could
assist us w/ our ambition to start building the attached distributed grid
use-case?
Any wiki how-to (or full code samples) would be especially
28 matches
Mail list logo
