Memcached StorageService

[Cantor, Scott]

On 10/2/14, 12:45 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>By associated keys, I assume you mean one key holds a list of the keys
>of all entries belonging to the context.

I believe so (I didn't write it but I looked at the method briefly).

> Assuming that's correct I
>wanted to avoid that for performance reasons as well as boundary
>problems. I didn't want to worry about the edge case (probably
>far-fetched) where adding an item to a list causes the data to exceed
>1M (max default entry size) and the write fails.

It detects that, I think, but just fails the write, and it's not a
practical concern for the most part when it comes to tracking keys.

> Of course you could
>do a bucketized list where you break up list items among multiple keys
>(index % numBuckets, for example), but I didn't think the complexity
>was worth it. I'm happy to reconsider.

I think it's worth having the feature to avoid having problems later on,
but I don't consider it a blocking issue right now, just something to file
an issue against for future work.

>> I admit I still don't "get" how it provides HA given no replication
>
>You're not alone. In any case I went to a fair amount of trouble to
>describe the failure characteristics in a HA environment for the CAS
>use case, which I think is relevant here as well:

Thanks for the link.

I found a PGP key for your email address, so I'll send you an initial
password under it and a link to the password changer when I get the LDAP
entry created.

-- Scott