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

[Mircea Markus]

On 11 May 2011, at 15:53, Sanne Grinovero wrote:

> 2011/5/11 Mircea Markus <mircea.markus at jboss.com>:
>> On 11 May 2011, at 13:29, Sanne Grinovero 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.
>> good point :-)
>> ConsistentHashMembershipChange perhaps?
>>> 
>>> 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?
>> @ViewChanged  listener is a CacheManager listener, so it's independent of the caches in that are in use. It is possible for the CacheManager to wait for all its distributed caches to install the view first, and only then dispatch the @ViewChange event,
>> Not sure that's a good idea in the general case, though.
> 
> let's talk about use cases. As an application developer building
> something cool on top of Infinispan, what's the point in receiving an
> event about new nodes being joined, if they're not ready to be used?
> I'd rather have you notify me when new nodes joined and I can actually
> start using them; the rest is low-level detail that an application
> shouldn't worry about - I think - but I'm ready to take it back if you
> find an example for which that's not true.
TBH I can't find a convincing-enough use case to write down :-) 
There is a small semantic (again theory!) difference between @ViewChanged and @NodeJoined (which is a really cool replacement-name for ConsistentHashMembershipChange btw).
ViewChange happens sooner than NodeJoined. This can be a matter of nanos or even seconds (timeout is by default 10 secs)  - depending on how long the state transfer takes. 
I'd love to see other opinions around this as well.