There are some issues with the riak_kv API which will be fixed in a
future release, but long story short, riak_kv_get_fsm:start_link doesn't
always actually end up linking the caller to the new FSM process. This
would cause the supervisor to end up with an endlessly growing list of
workers, since it had no way of seeing when a child died.
To fix this resource leak, we can simply switch to starting the process
directly, instead of using the supervisor API call. There's really no
reason to run these processes under a supervisor anyway since they're
normally started up under sidejob.
Note that in 2.2 this fix may be reworked again to use whatever new
APIs we end up adding/changing in riak_kv.
There are some issues with the riak_kv API which will be fixed in a future release, but long story short, riak_kv_get_fsm:start_link doesn't always actually end up linking the caller to the new FSM process. This would cause the supervisor to end up with an endlessly growing list of workers, since it had no way of seeing when a child died.
To fix this resource leak, we can simply switch to starting the process directly, instead of using the supervisor API call. There's really no reason to run these processes under a supervisor anyway since they're normally started up under sidejob.
Note that in 2.2 this fix may be reworked again to use whatever new APIs we end up adding/changing in riak_kv.
For more info, see basho/riak_kv#1178 (RIAK-2157)