[infinispan-dev] HotRod server and Rolling Upgrades

[Tristan Tarrant]

So,
I thought we had everything ready to go for HotRod rolling upgrades:

  * have HotRod server full of data (the "source")
  * configure a new HotRod server (the "target") with a RemoteCacheStore
    pointing to the "source" (using "rawValues")
  * clients switch over to the "target" server which on cache misses
    should seamlessly fetch entries from the "source"
  * issue a "dump keys" on the source
  * fetch the "dumped keys" from the target
  * disable the RCS on the target and switch off the "source" for good
  * PROFIT$$$

Unfortunately there is a teeny tiny flaw in the plan: entries in a 
HotRod-managed cache are ByteArrayKey/CacheValue pairs and 
unfortunately, when the "target" reads from the RCS they get unwrapped 
into their byte[] equivalents.

The solutions we have are:

 1. have a special marshaller placed on the RemoteCacheStore's
    RemoteCacheManager which rewraps the entries. Unfortunately
    marshallers can't distinguish between keys and values, so this would
    probably require some horrid ThreadLocal trickery
 2. Add a new option to RemoteCacheStore so that it rewraps entries in
    the ByteArrayKey/CacheValue format. Unfortunately the CacheValue
    class is part of server-core, but the dependency could be made
    optional, and in the context of the Rolling Upgrade scenario it is a
    non-issue, since it will be in the classpath
 3. Introduce a new MigrationRemoteCacheStore which does the same as the
    above, but without changing RCS itself.

My personal favourite is number 2, but I trust your better judgement.

I think these are merely workarounds and we should have a better way for 
"entry wrappers" (such as the cache servers) to "localize" the entries 
for their own particular needs. Also I believe we need a better way to 
attach metadata to entries in a portable way so that we don't need these 
value wrappers.

Tristan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121211/11ebad96/attachment.html