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(a)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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev