[infinispan-dev] HotRod server and Rolling Upgrades

[Dan Berindei]

+1 to eliminate the value wrappers.

-1 to adding a dependency from core to server-core, if you feel creating
and maintaining a separate MigrationRemoteCacheStore is too much work I'd
rather we moved CacheValue to core.

If we move CacheValue to core, I think we can do the re-wrapping on the
rawValues branch and avoid adding another setting to the RCS configuration.



On Tue, Dec 11, 2012 at 3:02 PM, Tristan Tarrant <ttarrant at redhat.com>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/b69367e4/attachment.html