+1 to eliminate the value wrappers.<br><br>-1 to adding a dependency from core to server-core, if you feel creating and maintaining a separate MigrationRemoteCacheStore is too much work I'd rather we moved CacheValue to core.<br>
<br>If we move CacheValue to core, I think we can do the re-wrapping on the rawValues branch and avoid adding another setting to the RCS configuration.<br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 3:02 PM, Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
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.<span class="HOEnZb"><font color="#888888"><br>
</font></span></p><span class="HOEnZb"><font color="#888888">
<p>Tristan<br>
</p>
</font></span></div>
<br>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></div><br></div>