Suppose a container server is under load and a new object is put in to the system. The object will be immediately available for reads as soon as the proxy server responds to the client with success. However, the container server did not update the object listing, and so the update would be queued for a later update. Container listings, therefore, may not immediately contain the object.
When Swift returns success for a PUT operation, you are guaranteed that it has written quorum (i.e. (numReplicas / 2) + 1). For example, with a 3x replica policy, two replicas will be written before the write request is confirmed. Since only one replica needs to be available for an object to be read, the object is immediately available. Remaining replicas are written during the normal object replicator service cycle and placed according to the ring configuration.
As to whether it exists in the container listing, that can be a bit more complicated. In the Liberty release, there is a configuration setting called container_update_timeout with a default value of 1. That says that if the object server gets confirmations from the container service in less than 1 second, then updates happen synchronously and are guaranteed when success is returned to the client. However, if the container service takes longer than that, or if the value is set very low (e.g. 0), then container updates will be bundled together and submitted to the container service asynchronously.
This was done to improve performance in multi-region deployments where the container metadata being updated may not exist in the same data center, or even the same country, as the object service requesting the update.
Asked in February 2016Viewed 1,698 timesVoted 8Answered 2 times