code structure for append needs refactoring #59
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: greg/machi#59
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hrm. With the introduction of eleveldb for max offset & checksum storage, the overall flow for
append
operations is now messy IMHO and needs refactoring.For example, given a max file size rollover, there's an icky race between machi_flu_filename_mgr and machi_flu_append_server and machi_file_proxy. It's the file proxy proc that decides that it's time to rollover, but there are already append filename assignments by machi_flu_append_server (in collusion with the filename server) but not yet file offsets (which are assigned by file proxy).
For example, try a stress test using basho_bench, large'ish appends (e.g. 256KB or 1MB), and a small
max_file_size
value inapp.config
(e.g. 10MB). It works, but max latencies are absurdly high while a rollover is in progress. Also, the logs show that it's likely for a file to be closed for rollover twice. The second time is caused by racing straggler operations that are forwarded to a new file proxy proc.