<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Even then, #2 would only be a temporary solution until we have #4, right? Would <a 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 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 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>
</div>
_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</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 href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div><div>Platform Architect, JBoss Data Grid</div><div><a href="http://red.ht/data-grid">http://red.ht/data-grid</a></div></div></div></span></div></span></div></span>
</div>
<br></div></div></body></html>