Allowing duplicates was breaking the pipe and kv unit tests.
Avoid use of ets:match() in hot code paths Profiling with DTrace on Solaris suggests that ets:match() is causing a much higher than necessary lock contention rate within the Erlang R14B03 and R14B04 VMs. Eliminating ets:match() in the riak_core and riak_kv applications is substantial when using Pthread locking instead of Ericsson's hand-tuned locking (which is the default). The results are more ambiguous when the default locking strategy is used. Hand-edits were required due to changes in master after the 1.0 branch was created.
Change trigger_handoff and finish_handoff events in the vnode to be ignored if the vnode modstate is already deleted. Add periodic timer to vnode manager to perform various management activities. Currently re-triggers ownership handoff so that handoff under load is not triggered only on ring changes.
Move forwarding and handoff decisions from individual vnode processes and into the vnode manager. The vnode manager makes handoff and forwarding decisions whenever the ring changes, and triggers vnode state changes as appropriate. Rewrite the logic by which per vnode handoff is marked as complete in the ring. In particular, move the logic from riak_core_gossip and into riak_core_vnode. The underlying ring changes are still serialized by riak_core_ring_manager through the ring_trans function. Change gossip throttling logic to trigger gossip whenever gossip tokens reset, replacing the gossip interval approach. Perform various tuning and additional minor changes that improve cluster operation during a heavy gossip spike.
Now that handoff_concurrency enforces both outbound and inbound connections there is a chance that the receiver will decide to reject the incoming handoff and close the socket. Since the current protocol has no way to express this the sender must assume that a socket handup is the receiver rejecting the handoff. This is a normal occurance and should not be logged as an error/warning.
Now that the handoff sender and vnode are no longer linked it is unsafe to use the master's `sync_command` call. If the vnode fails the sync_command call will never return and the sender will be stuck indefinitely unless it is manually killed at the console. Adding a timeout could fix this but would cause other complications if you set it too low. This patch gets around the issue by using a helper process to perform the fold. The sender process then monitors the vnode and spawn_links the helper. If either the vnode or helper gets into trouble the sender will know about it. In the happy path the sender will get the fold result back and exit cleanly.