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

2011/5/11 Mircea Markus <mircea.markus(a)jboss.com&gt;: > 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.