On Dec 14, 2012, at 2:56 PM, Tristan Tarrant <ttarr...@redhat.com> wrote:
> 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). ^ +1 - I think that would get rid of unnecessary wrapper values (which get wrapped again in ICE…) > 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. ^ Somehow related to this, Tristan made an interesting suggestion last week wrt Hot Rod key type. Right now this is a ByteArrayKey, which wraps an array and provides content based equals() implementation. It would be interesting to allow byte[] to be stored as keys directly, and instead do the comparison via some Comparator implementation. This would get rid of the wrapper class. I will add a note to ISPN-2281 on this. Cheers, > 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 <der...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
