This line was removed.
This word was removed. This word was added.
This line was added.
Changes (4)View Page History
In the response, the keystate field is intended to be a bitmask for various states. For example:
0x80 = not found, not persisted
0x00 = found, not persisted
0x01 = found, persisted
0x01 = found, persisted
0x81 << an impossible condition
0x81 = logically deleted
This is primarily because replication can potentially be significantly behind the initial create and we do not want to receive a NOT_FOUND error for the entire set of items being observed in that state. The intent of this being a bitmask is that future extension could allow for this field to indicate if the item is considered in any indexes, etc. Error masks start from the top of the field.
It is important for client developers to understand the difference between not found and logically deleted. If a client does a set then not found and logically deleted mean mean the same thing from the clients perspective. For a set the first thing the client needs to know is whether or not an item has made it to the appropriate servers and in this case both not found and logically deleted mean that this hasn't happened yet. In the case of a delete not found and logically deleted mean two different things. If you are returned not found for a delete then you can assume that the delete has been persisted on that node, but if you are returned logically deleted then it means that the delete has made it to the server, but has not yet been persisted.
Also, in the response above, the field normally used for CAS has been separated into two fields which are to provide statistics on the average amount of time for certain events to propagate from a given server. The first is the amount of time, in milliseconds, it's taking on average to persist items. The second is the amount of time, in milliseconds, it's taking to replicate items. If not implemented by a given server version, each of these fields would be padded with 0. These fields allow a client library to optionally be a bit more intelligent, and thus efficient, about its polling intervals. The examples above show 1000 milliseconds to persistence and 100 milliseconds to replication. Note that this is a server's best guess on how long things take on average for any given operation, it is not related to the specific key being observed.