2011/5/16 Galder Zamarreņo <galder@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.