On 09/19/2013 09:24 AM, Galder ZamarreƱo wrote:
a) Bring back Infinispan 5.x classes to 6.0 to be able to read 5.x
cache stores directly from 6.0.
No, we need something that is version independent
(aside from the actual
payload, for which the user is responsible).
b) Develop some code for Infinispan 5.x to dump cache store data into
a file or somewhere in a given format and then read
This is something we may want to
do anyway, and it's the one that
requires the least amount of setup.
c) Use CLI to connect from new cluster to the old cluster and fetch
all keys.
I think the easiest thing would be to do c), developing a CLISourceMigrator (implements
org.infinispan.upgrade.SourceMigrator) to be able to read all keys from the source
embedded cluster. However, I don't see anywhere in the CLI a command that returns back
all keys. Upgrade with DUMPKEYS simply calls up the local
SourceMigrator.recordKnownGlobalKeyset. We'd need such a command in Infinispan 5.x and
6.x, the former to send all keys and the latter to request them.
"dumpkeys" is actually a misnomer that I want to drop eventually, since
it was based on a limitation of HotRod which didn't provide a way to get
all keys in a "protocol-aware" way. I'd rather call that the "source
prepare" step.
We'd also need a CLITargetMigrator which is pretty
straightforward to do since once we have all keys, it's easy to loop through them and
request them using CLI's Get operation.
@Tristan, you're the rolling upgrade meister, how does this sound? If we get this
right, we'd not only get cache store migration, but also embedded/library cluster
rolling upgrade.
My question: how would the target connect to the source ? A
temporary
HotRod connection ? Some kind of JGroups bridge (would only work if the
source/target use clustering) ?
Tristan