
<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

  </head>

  <body 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.<br>

    </p>

    <p>Tristan<br>

    </p>

  </body>

</html>