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

[Dan Berindei]

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
>