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
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
