Two questions about exptime and replication consistency. about mcrouter

[pavlo-fb]

Hi @deep011

1. Short answer: yes, expiration time in cold pool will not be the same as in warm pool.
   Long answer: WarmUpRoute was updated in today's release, now it can set the correct expiration time. But it uses META command to achieve this, which is an extension to memcache protocol introduced in facebook fork of memcached (https://github.com/facebookarchive/memcached). This repo is not supported anymore though. The only option I see is to implement META in upstream memcached.
   Currently you can workaround this issue by setting some small exptime in WarmUpRoute to make sure value in cold pool expires faster than in warm pool.

2. Lets assume the keys are consistent if all sets and deletes to all the replicas succeeded.
   If one uses AllSyncRoute for sets/deletes, mcrouter will return "successful" reply (e.g. STORED/DELETED/NOT_FOUND) only when all replicated requests have succeeded. Client is responsible to retry in case of error, so we can make sure all replicated requests are delivered.

[deep011]

Hi @pavlo-fb
Thank you for this reply.

1. That is to say if i want keep the expiration time consistent, i must use the facebook fork of memcached?

2. When one replicated request is successful and another replicated request is failed, is the key in those memcached servers are not same? If so, the next time we get this key, the value maybe dirty. I do not know if you can understand what I mean.

[alikhtarov]

@deep011

1. We don't encourage using the old Facebook memcached fork, as it's not supported anymore.
   Basically there's no way to ask open source memcached about the exptime of an item, so there's no way to set the exact exptime on the new item. You can only approximate by setting a smaller exptime intentionally.
2. Yes, it's possible for a set to succeed in only one replica. Since the second set will fail, the client will think that the whole request "failed", and there are a few options: issue a delete for the same key (assuming deletes are reliable - that can be achieved with a reliable delete log, see asynclog option); or retry the set.

[deep011]

@alikhtarov
thank you for this reply.
For some abnormal situation, if the data are inconsistent among the replicas, what you will do?

[alikhtarov]

@deep011 Sorry for the late reply. In these cases, if the service cannot tolerate stale data then on the publisher side we check that the set succeeded in all replicas (you can do it with a special config that would route to one replica at a time).