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

[Mircea Markus]

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. 
> 
> 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