[infinispan-dev] HotRod server and Rolling Upgrades

[Dennis Reed]

I don't like #1.  Seems more complicated, harder to maintain & debug 
than the others.

In my opinion the best option would be #4 (eliminate the different 
formats), but that probably can't be done in a minor release?

Between 2 and 3, I'd prefer #2, handling it in the base class so it's 
automatically inherited by any custom classes that extend it.
Since the use case isn't limited to rolling upgrades; you could have a 
HotRod cache with a full-time RemoteCacheStore.

-Dennis

On 12/11/2012 07:02 AM, Tristan Tarrant wrote:
> 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
>
>
> _______________________________________________
> 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/20121211/34a45bac/attachment.html