[infinispan-dev] HotRod server and Rolling Upgrades

[Manik Surtani]

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 <dereed at redhat.com> 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
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121214/2078aed8/attachment-0001.html