- Always set values to keys that have no defaults in schema, as setting a value to `undefined` does not return the "default" value when application:get_env/3 is called
- Provide an easier way to get the configuration by creating the config record, with appropriate defaults
- Code cleanup on BKV1/2/3 - make them easier to read/understand and for future work in refactoring the tests and removing some of the complexity.
- Now that test is running more consistently, tighten tests to actually test something in test_vnode_protection.
- Bump vnode protection to ?THRESHOLD+1 as 2.0 seems to have one extra message.
- Convert lager:info to lager:debug in successful get cases to reduce noise.
- Remove use of ConsistentType (use macros & pass BKV down to validate).
- Actually test FSM protection - previous limits didn't actually test overload at all. Now stop vnode and do an exact count of how many FSMs should have spun up.
- Make sure to wait for riak_kv before suspending any vnodes.
- Found sidejob race condition and updated test to compensate.
Added send of junk message through proxy to force vnode proxies into
overload state - without it, the first messgage would be forwarded to
the vnode and time out, which caused the test to fail.
This test's a little confused in the sources as-is since it prints
like it's based on the number of requests, even though the actual
comparison is done against a function of THRESHOLD. I've reverted
to the comparison used currently, since it looks to me like this
test should really expect to have ~NUM_REQUESTS processes, and a
vnode queue pretty close to THRESHOLD. I'd appreciate review here
though, particularly if anyone recalls the original intent of
these comparison numbers.
Previously we'd used a sort of fuzzy 'metric' where we expect the
number of successful requests/fsms to be less than some fudge
factor over the overload threshold. This tends to kick up spurious
failures on the test board without offering much more in the way
of assurances about overload's functionality.
This change instead bases test success on the number of requests
only, not the threshold — if some amount of work was shed at all
we consider that a passing test.
In the future we should revisit this and change the request
accounting machinery to just explicitly track denials instead of
fsm processes / vnode queue depth.
