<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5">
</HEAD>
<BODY>
On Tue, 2016-01-19 at 21:28 +0000, Marvin Addison wrote:
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
So, is this normal behavior, and I read too much into MemcachedStorageService's ability to handle failover?
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
I believe the docs need to be updated. We recently discovered during an outage that locatorType="CONSISTENT" prevents rehashing the key against the reduced pool, which effectively leads to non-deterministic failures for storage events. Basically anything that hashes to the downed node will fail. We changed locatorType="ARRAY_MOD" and achieved the resiliency we were after. Please make that change and report back. I will probably update the docs either way; I'm fairly sure it's the best setting for most deployments.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
Thanks for the response. At least for my logout test case, locatorType="ARRAY_MOD" exhibits the same behavior as locatorType="CONSISTENT". However, it appears that the ARRAY_MOD *seems* to handle errors better for my test case when an existing logged in user tries to access a new SP after one of the memcache servers was forced out of the pool. I put an asterisk on that because I wonder if it matters which node I take down in my simulation. ARRAY_MOD doesn't seem to generate all of the errors I was seeing in my original test case, but I have not had the time to do an exhaustive test.<BR>
<BR>
Anyway, part of my confusion was due to some of the wording on the wiki that said that there wasn't a need to setup repcached and the keys would be written/retrieved from the backup node. After rereading it, I see I glossed over the part where not all use cases can handle the failover situation the same.<BR>
<BR>
Thanks,<BR>
<BR>
-daniel
<BR>
</BODY>
</HTML>