[infinispan-dev] HotRod server and Rolling Upgrades

[Tristan Tarrant]

I would really like ISPN-2281 to be solved by the proper solution, i.e. 
attach any additional metadata required by the servers (or any other 
data "enricher") to the InternalCacheEntry and not as part of the value 
itself. Metadata would be some kind of sparse structure whose values 
could also be inherited implicitly by Cache-level metadata (to save memory).

Let's think about data typing: "a string is a string is a string", and 
not some weirdly marshalled byte array (which may be influenced by 
Marshaller, protocol value wrapper, phase of the moon, etc). Protocols 
would say "this is a string" (e.g. REST via Content-type: text/plain, 
InVM by just storing a java.lang.String) and the server would store it 
in an "as-native-as-possible" format, recording the type along with it. 
When someone retrieves it it needs to be translated to something the 
client understands. Obviously if I'm going to have a Cache of Strings, 
that metadata would be "global" to the cache and entries would not have 
that information.

Was this ever planned ? Canned ? Banned ?

Tristan

On 12/14/2012 01:14 PM, Manik Surtani wrote:
> 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 
> <mailto: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:
>>>
>>>  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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org <mailto:manik at jboss.org>
> twitter.com/maniksurtani <http://twitter.com/maniksurtani>
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
>
> _______________________________________________
> 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/20121214/ad5404f2/attachment.html