[asterisk-scf-dev] Changes regarding state replicator keys

[Mark Michelson]

On 12/17/2010 12:02 AM, David M. Lee wrote:
> On Dec 16, 2010, at 5:56 PM, Mark Michelson wrote:
>
>> So making the conversion a non-member function is expressly forbidden in the second case. In the first case, the compiler seems a bit...confused. It's certainly possible I messed up the syntax though.
> No, I think you're right.  const char* is the proper return type for the function, not char[].  So non-member conversion functions are out of the question.
>
> Options:
>
> 0. I still think that just having string keys is the best option.  I worry about what might happen if the key class gets sliced.  Probably not a valid use case (a client using a derived class of K for the key), but there's no easy way to catch those sort of errors.  If there is some class that makes more sense for a key, adding a toString() function to the class shouldn't be onerous.
>
> 1. Require K to have member functions c_str() and size().  std::string fulfills this contract, so it can be used as-is.  It's probably a bit odd for other classes we might want to use for K.
>
> 2. Require K to have a member function toString(), which returns a std::string or const std::string&.  We can specialize the template to accept std::string as a type for K.  Might lead to some code duplication between the StateReplicator template and its specialization.
>
> dave
> <><
Welp, I've hit another "fun" little snag with regards to libmemcached.

There's no reliable method to grab all items from memcached. There is a 
function called memcached_dump() whose man page states the following:

"memcached_dump() is used to get a list of keys found  memcached(1) 
servers.  Because memcached(1) does not guarentee to dump all keys you 
can not assume you have fetched all keys from the
        server. The function takes an array of callbacks that it will 
use to execute on keys as they are found.

  Currently the binar protocol is not supported."

(typos are copied directly from the man page)

Looking in the source and at Google searches, I can't find why or under 
what circumstances memcached would not report all keys. The extra 
limitation that libmemcached doesn't support the memcached binary 
protocol for the operation seals it for me; I can't use this function in 
our code.

That just leaves memcached_mget(), which requires an array of keys to be 
passed as an argument. This would imply that the 
MemcachedStateReplicatorStorage class would have to maintain a container 
of keys so that all state items stored in memcached can be retrieved 
when StateReplicator::getAllState() or StateReplicator::addListener() is 
called. As Dave pointed out in an earlier posting, keeping such data 
invalidates the use of memcached in the first place.

I'm going to send an e-mail to the libmemcached mailing list and try to 
find out under what circumstances memcached_dump() will not retrieve all 
keys. It may turn out that the circumstances are unique or bizarre and 
we may be able to work around it. Stay tuned.