object-updater should remember redirects and proactively check whether an update should be pointing at a shard instead
Bug #1878090 reported by
Tim Burke
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
One of the troubles you get with a large container is that async pendings start piling up pointing at it because the container can't keep up. Once you shard it, the container server will issue redirects to appropriate shards, but it can still only send so many at a time.
Instead of making two requests for every async pending (one to get the redirect, one to update the shard instead), the updater should get the whole set of shards loaded into its head after the first redirect, and use that information to avoid further requests to the root.
To post a comment you must log in.
Is there any rule that says the container server can't return the shards list as part of the 301?
Should there be any limit on how many shards and how long the updater can cache these?