[infinispan-dev] https://issues.jboss.org/browse/ISPN-977

[Erik Salter]

Wouldn't any rehash affect the locality of these generated keys, or am I missing something?

Erik

-----Original Message-----
From: infinispan-dev-bounces at lists.jboss.org [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Dan Berindei
Sent: Wednesday, May 11, 2011 12:47 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] https://issues.jboss.org/browse/ISPN-977

On Wed, May 11, 2011 at 5:51 PM, Mircea Markus <mircea.markus at jboss.com> wrote:
>
> On 11 May 2011, at 13:57, Dan Berindei wrote:
>
>> With the new push-based rebalancing code, we install the new CH
>> before doing any rebalancing work, so the inconsistency window should
>> be much smaller.
>> In theory we also block new transactions, maybe you could use that to
>> stop generating new keys while rehashing.
> that's sounds interesting, I'll take a look!
>>
>> On the other hand, in 5.0 you should be able to implement
>> KeyAffinityService on top of Pete's grouping work for
>> https://issues.jboss.org/browse/ISPN-312 and then you won't need any
>> listeners.
> Not sure how could that work? KAS generates pseudo-random keys that map to a certain nice. It's up to the user to place them in cache at some point, if ever.

I was thinking of wrapping the keys generated by the user's KeyGenerator together with a node address in our own MagicKey class and set the @Group annotation on the address field.
We already have a MagicKey class for testing, the only problem with it is that it only uses the address for hashing so you'd get lots of collisions. With Pete's changes MagicKey becomes something we can actually expose to the users (I was thinking through the KeyAffinityService API).

I didn't think this through however, because MagicKey<K> would have to extend K in order to satisfy the KeyAffinityService API (and even to be able to store the key in the Cache<K,V> later).

Your question does raise an interesting point, though: a new node can join between the user call to
KeyAffinityService.getKeyForAddress(address) and Cache.put(generatedKey), making generatedKey map to the new node. So there is no way for us to completely eliminate the issue of "stale"
keys.


>>
>> Dan
>>
>>
>> On Wed, May 11, 2011 at 3:29 PM, Sanne Grinovero
>> <sanne.grinovero at gmail.com> wrote:
>>> First thing I thought when reading your email was "OMG do we support
>>> on-the-fly hash implementation changes? crazy!"
>>>
>>> That's obviously not the case, but if you name it as
>>> @ConsistenHashChangeListene that's what I would think.
>>>
>>> Wouldn't it be better to change the exact timing of the viewchange
>>> event? I don't see why Infinispan users might be more interested in
>>> knowing about the topology details according to the transport than
>>> what they are about the actual Infinispan hashing topology - I would
>>> expect that when I receive which notification the new view is
>>> already installed and ready to go; actually I thought that was the
>>> case since ever.
>>>
>>> What would be the use cases to get the notification *before* the new
>>> hash is installed?
>>>
>>> Cheers,
>>> Sanne
>>>
>>> 2011/5/11 Mircea Markus <mircea.markus at jboss.com>:
>>>> Hi,
>>>> The basic problem behind this is that I need to be notified when a
>>>> new consistent hash is installed.
>>>>
>>>> ATM there isn't any support (of which I know)  for  a
>>>> "@ConsistenHashChangeListener".
>>>>
>>>> I'm thinking to add such notifications either:
>>>> a) internally: Observer pattern on DistributionManager or even on
>>>> DistributionManagerImpl
>>>> b) more generically, as a fully flagged listener.
>>>>
>>>> I favor a) and then if more people ask for it we will expose it as
>>>> a fully flagged listener.
>>>>
>>>> Suggestions?
>>>>
>>>> Cheers,
>>>> Mircea
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.