On 16 May 2011, at 12:18, Sanne Grinovero wrote: > 2011/5/16 Galder Zamarreño <gal...@redhat.com>: >> Not sure if the idea has come up but while at GeeCON last week I was >> discussing to one of the attendees about state transfer improvements in >> replicated environments: >> >> The idea is that in a replicated environment, if a cache manager shuts down, >> it would dump its memory contents to a cache store (i.e. a local filesystem) >> and when it starts up, instead of going over the network to do state >> transfer, it would load the state from the local filesystem which would be >> much quicker. Obviously, at times the cache manager would crash or have some >> failure dumping the memory contents, so in that case it would fallback on >> state transfer over the network. I think it's an interesting idea since it >> could reduce the amount of state transfer to be done. It's true though that >> there're other tricks if you're having issues with state transfer, such as >> the use of a cluster cache loader. >> >> WDYT? > > Well if it's a shared cachestore, then we're using network at some > level anyway. If we're talking about a not-shared cachestore, how do > you know which keys/values are still valid and where not updated? and > about the new keys? > > I like the concept though, let's explore more in this direction. +1. During startup the resurrected node can load some state from local store and remaining/deltas through state transfer. That's if deltas are determinable - perhaps with some Merkle trees, or by application. This problem sounds similar with solving a merge.
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
