Feature #14040
closed
Added by Samuel Just over 8 years ago.
Updated over 7 years ago.
Description
Partial updates will require an RMW. This needs to be implemented. Replace this description with a design strategy before writing any code.
- Status changed from New to In Progress
- Assignee set to Samuel Just
- % Done changed from 0 to 10
- % Done changed from 10 to 60
RMW code mostly written. Annoying detail: the R in RMW implies a second layer of projection since ops which haven't begun the write part yet won't be reflected in either the info or the log (and it needs to be that way since peering assumes anything in our in-memory info/log state has been submitted to the store). I think it's not so bad, we need whatever we need to serve new writes and construct new log entries along with whatever we need to make decisions about whether a write is an append or not in get_write_plan. We can safely let ObjectContexts hold the fully projected version of the object_info since we don't rely on them if the pipeline is interupted (interval change causes a clean ObjectContext slate). I think all we really need from the info and log are last_update and stats -- and we can ignore stats if we choose to pass it all the way through as a delta.
This also breaks the error and missing entry propogation.
May not be too bad, move apply_ctx_stats into PG append_log_entries (or w/e) method to be run on commit and pass the state to the backend and through to the replicas (how are the stats currently getting there? I bet we are reading the info from the backend...)
Yeah, we're reading it out of the PG state, so don't do that (do make sure to update the replica stats!).
Updated the submit_log_entries code to pass back to the backend. Also added projected_last_update and delta_stats to avoid updating last_update in line.
- % Done changed from 60 to 80
- Status changed from In Progress to 7
- Status changed from 7 to Resolved
Also available in: Atom
PDF