<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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).<br>
<br>
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.<br>
<br>
Was this ever planned ? Canned ? Banned ?<br>
<br>
Tristan<br>
<br>
On 12/14/2012 01:14 PM, Manik Surtani wrote:<br>
</div>
<blockquote
cite="mid:E53612BD-3989-43C5-858D-8A8EB33E0AE1@jboss.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Even then, #2 would only be a temporary solution until we have #4,
right? Would <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-2281">https://issues.jboss.org/browse/ISPN-2281</a> help
in any way?
<div><br>
</div>
<div>- M<br>
<div><br>
<div>
<div>On 11 Dec 2012, at 17:37, Dennis Reed <<a
moz-do-not-send="true" href="mailto:dereed@redhat.com">dereed@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#ffffff" text="#000000"> I don't like #1.
Seems more complicated, harder to maintain & debug
than the others.<br>
<br>
In my opinion the best option would be #4 (eliminate the
different formats), but that probably can't be done in a
minor release?<br>
<br>
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.<br>
Since the use case isn't limited to rolling upgrades;
you could have a HotRod cache with a full-time
RemoteCacheStore.<br>
<br>
-Dennis<br>
<br>
On 12/11/2012 07:02 AM, Tristan Tarrant wrote:
<blockquote cite="mid:50C72F00.50201@redhat.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
So,<br>
I thought we had everything ready to go for HotRod
rolling upgrades:<br>
<br>
<ul>
<li>have HotRod server full of data (the "source")</li>
<li>configure a new HotRod server (the "target")
with a RemoteCacheStore pointing to the "source"
(using "rawValues")</li>
<li>clients switch over to the "target" server which
on cache misses should seamlessly fetch entries
from the "source"</li>
<li>issue a "dump keys" on the source</li>
<li>fetch the "dumped keys" from the target</li>
<li>disable the RCS on the target and switch off the
"source" for good<br>
</li>
<li>PROFIT$$$</li>
</ul>
<p>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.<br>
</p>
<p>The solutions we have are:<br>
</p>
<ol>
<li>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</li>
<li>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<br>
</li>
<li>Introduce a new MigrationRemoteCacheStore which
does the same as the above, but without changing
RCS itself.</li>
</ol>
<p>My personal favourite is number 2, but I trust your
better judgement.<br>
</p>
<p>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.<br>
</p>
<p>Tristan<br>
</p>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
infinispan-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
</div>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote>
</div>
<br>
<div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse:
separate; border-spacing: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space; "><span
class="Apple-style-span" style="border-collapse:
separate; color: rgb(0, 0, 0); font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; border-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space; "><span
class="Apple-style-span" style="border-collapse:
separate; color: rgb(0, 0, 0); font-family:
Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
border-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; font-size: medium;
">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; ">
<div>--</div>
<div>Manik Surtani</div>
<div><a moz-do-not-send="true"
href="mailto:manik@jboss.org">manik@jboss.org</a></div>
<div><a moz-do-not-send="true"
href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div>
<div><br>
</div>
<div>
<div>Platform Architect, JBoss Data Grid</div>
<div><a moz-do-not-send="true"
href="http://red.ht/data-grid">http://red.ht/data-grid</a></div>
</div>
</div>
</span></div>
</span></div>
</span>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
</body>
</html>