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 <der...@redhat.com
<mailto: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:
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org <mailto:ma...@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@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
