Even then, #2 would only be a temporary solution until we have #4, right? Would https://issues.jboss.org/browse/ISPN-2281 help in any way?
- M On 11 Dec 2012, at 17:37, Dennis Reed <[email protected]> wrote: > 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: >> 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 >> 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 >> 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 -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
