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

[Mircea Markus]

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:

> Hi guys
> 
> It's been a long time coming, but I finally published the non-blocking
> state transfer draft on the wiki:
> https://community.jboss.org/wiki/Non-blockingStateTransfer
> 
> Unlike my previous state transfer design document, I think I've
> fleshed out most of the implications. Still, there are some things I
> don't have a clear solution for yet. As you would expect it's mostly
> around merging and delayed state transfer.
> 
> I'm looking forward to hearing your comments/advice!
> 
> Cheers
> Dan
> 
> PS: Let's discuss this over the mailing list only.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120320/745eba4f/attachment-0001.html