Re: [infinispan-dev] Non-blocking state transfer (ISPN-1424)

Hi Dan, Some notes: Ownership Information: - I remember the discussion with Sanne about an algorithm that wouldn't require view prepare/rollback, but I think it would be very interring to see it described in detail somewhere as all the points you raised in the document are very closely tied to that - "However, it's not that clear what to do when a node leaves while the cache is in "steady state"" --> if (numOwners-1) nodes crash a state transfer is (most likely) wanted in order not to loose consistency in the eventuality another node goes down. By default numOwners is 2, so in the first release, can't we just assume that for every leave we'd want immediately issue a state transfer? I think this would cover most of our user's needs and simplify the problem considerably. Recovery - I agree with your point re:recovery. This shouldn't be considered hight prio in the first release. The recovery info is kept in an independent cache, which allows a lot of flexibility: e.g. can point to a shared cache store so that recovery caches on other nodes can read that info when needed. Locking/sync.. "The state transfer task will acquire the DCL in exclusive mode after updating the cache view id and release it after obtaining the data container snapshot. This will ensure the state transfer task can't proceed on the old owner until all write commands that knew about the old CH have finished executing." <-- that means that incoming writes would block for the duration of iterating the DataContainer? That shouldn't be too bad, unless a cache store is present.. "CacheViewInterceptor [..] also needs to block in the interval between a node noticing a leave and actually receiving the new cache view from the coordinator" <-- why can't the local cache star computing the new CH independently and not wait for the coordinator..? Cheers, Mircea On 8 Mar 2012, at 10:55, Dan Berindei wrote: