<div class="gmail_quote">On Tue, Sep 25, 2012 at 10:53 AM, Manik Surtani <span dir="ltr"><<a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div><div>On 24 Sep 2012, at 16:22, Dan Berindei <<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>> wrote:</div><br><blockquote type="cite">
Hi guys<br><br>During the final push for NBST I found a bug with preloading (entries that didn't belong on a joiner weren't removed after the initial state transfer). I decided to fix it and <a href="https://issues.jboss.org/browse/ISPN-1586" target="_blank">https://issues.jboss.org/browse/ISPN-1586</a> at the same time, since it was a longstanding bug and I had a reasonable idea on what to do. However, I missed some implications and I need to fix them - there is at least one Query test failing because of my change (SharedCacheLoaderQueryIndexTest).<br>
<br>In 5.1, preloading worked like this:<br>1. Start the CacheLoaderManager, which preloads everything from the cache store in memory.<br>2. Start the StateTransferManager, retrieving data from the other cache members and overwriting already-preloaded values.<br>
3. When the initial state transfer ends, entries not owned by the local node are deleted.<br><br>The main issue with this, raised in ISPN-1586, is that entries that were deleted on the other cache members are "revived" on the joiner when it reads the data from the cache store. There is another performance issue, because we load a lot of data that we then discard, but that's less important.<br>
<br>With the ISPN-1586 fix, preloading should work like this:<br>1. Start the StateTransferManager, receive initial CH.<br>2. If the local node is not the first to start up, fetching state (either in-memory or persistent) is enabled and the cache store is non-shared, clear it.<br>
3. Start the CacheLoaderManager, which preloads the cache store in
memory - but only if the local node is the first one having started the
cache OR if the fetching state is disabled.<br>4. Run the initial state transfer, retrieving data from the other cache members (if any, and if fetching state is enabled).<br><br>This solves ISPN-1586, but it does mean that data from non-shared cache stores will be lost on all the nodes except the first that starts up. So if the last node to shut down is not the first node to start back up, the cluster will lose data.<br>
<br>These are the alternatives I'm considering:<br>a) Finish the ISPN-1586 fix and clearly document that non-shared cache stores don't guarantee persistence after cluster restart (unless the last cache to stop is the first to start back up and shutdown was spaced out to allow state transfer to move everything to the last node).<br>
b) Revert my ISPN-1586 fix and allow "zombie" cache entries on the joiners (leaving ISPN-1586 open).<br></blockquote><div><br></div></div><div>Maybe another approach could be:</div><div><br></div><div>1. Start the STM, retrieve initial CH</div>
<div>2. If the local node… (as above) … is non-shared, *don't clear it*, but mark the node so preloading is *deferred*.</div><div>3. Start the CLM … skip preload if we mark it as deferred, in step 2.</div><div>4. Run initial state transfer. This will write newer versions of entries to the cache store if needed.</div>
<div>5. Now, if preloading has been deferred in step 2, start a preload, if we're configured to do any preloading.</div><div><br></div><div>This should give us consistency.</div><div><br></div></div></div></blockquote>
<div><br>Nope, this doesn't solve ISPN-1586: if the already-running members have deleted a key, the deferred preload on the joiner can still load that key from its cache store. In fact, the preload doesn't even matter here: just the fact that the key is still in the cache store means that the node can still return a non-null value for a deleted key.<br>
<br>This is why I added the clear step in my algorithm: to avoid resurrecting removed keys without receiving any tombstones through state transfer.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>
<blockquote type="cite"><br>I think there may be a third option: <br>c) Make preload a JMX operation and allow the user to run a cluster-wide preload once all the nodes in the cluster have started up. But this looks a little complicated, and it would require either versioning or prohibiting external cache writes until the cluster-wide preload is done to ensure consistency.<br>
</blockquote><div><br></div></div><div>I'm not sure how having this as a JMX option helps. Having versioning, etc. solves the problem even with an automatic preload.</div><br></div></div></blockquote><div><br>Agree, just having this as an option in JMX doesn't fix anything. But having it as a manual operation would allow us to assume (and document it this way) that the admin only exposes the cluster to the clients after preloading is done - so we'd have no concurrent changes to worry about.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>
<br>What do you guys think? Sanne, I'm particularly interested how you think option a) would fit with the query module.<br><br>Cheers<br>Dan<br><br></div><br>
</blockquote></div></div></blockquote></div><br>