94cc5ec6d6
To avoid opening a container database to handle every object update, the container server now only looks for a shard range to which an update might be redirected when the update originates from the object updater. This is inferred from the presence of an 'X-Backend-Accept-Redirect' header. Futhermore, the object updater only includes this header for updates that do not already have a redirection location cached in the async pending file/update data. Consequently: - updates from old updater daemons will not be redirected. - updates in the client PUT/DELETE path will not be redirected *again* (they will normally have had their update target 'redirected' by the proxy en route to the object server). - updates to a shard container will not be redirected because they will already have an update location from the root container. When a container first moves to sharded state, there will be a short period of time during which the proxy has not learnt that the container is sharding and will not re-target the object update. These updates will now land in the root misplaced objects table. Some changes to probe tests are needed to account for this altered behaviour. Change-Id: I3b0f500ca7082a3c96ed2fb72f13073a9c840773 |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| auditor.py | ||
| diskfile.py | ||
| expirer.py | ||
| mem_diskfile.py | ||
| mem_server.py | ||
| reconstructor.py | ||
| replicator.py | ||
| server.py | ||
| ssync_receiver.py | ||
| ssync_sender.py | ||
| updater.py | ||