Under-utilised Features - Long Term Plan

[martinsumner]

There are some features within riak_core, that are rarely or never used. Should these features simply be removed going forward.

riak_core_bg_manager

• Used potentially in three places: riak_repl fullsync (riak_repl.fullsync_use_background_manager); riak_kv handoff (riak_kv.handoff_use_background_manager); riak_kv hashtree aae (riak_kv.aae_use_background_manager).
• In all three cases by default the use of background manager is configured to off.

riak_core_throttle

• Used only within riak_kv_entropy_manager.

riak_core_table_owner

• Used only by riak_core_throttle (see above).

gen_nb_server

• Used in riak_core_handoff_listener, and in riak_api in riak_api_pb_listener.
• Reason why a specific non-block server for TCP handling is required unknown.
• Was previously used in riak_repl, but since replaced by use of ranch.
• Question whether dedicated riak_core_handoff_listener is needed, with improvements to Erlang Distribution Protocol that may help with potential issues with inter-node traffic being overwhelmed with handoff data?
• An alternative may be to use approach in nextgenrepl i.e. make handoff part of the API, and use the riak erlang client for handoff as this helps with issues with maintaining SSL/TLS compatability.

process_proxy

• Used only in riak_core_handoff_listener.
• Reasons unclear as to why it is required.

bloom

• Not used anywhere. riak_repl uses ebloom.

riak_core_tracer|riak_core_dtrace

• riak_core_tracer only used in riak_kv, within riak_kv_get_fsm eunit test.
• Do real-world Riak users use this?

riak_core_gen_server

• Taken from LShift/RabbitMQ originally - adds a priority queue in-front of the standard process mailbox. The RabbitMQ code still includes gen_server2 which appears to be an updated version of this.
• Used only in riak_core_handoff_receiver and within riak_repl in riak_repl_fullsync_helper, but no use of priority.
• Related PR for vernemq

riak_core_priority_queue

• Used only within riak_core_gen_server (see above).

[martinsumner]

Also:

riak_core_exo_monitor

• Is advertised as a way of bridging between "legacy" folsom stats i.e. defined as legacy mapping module folsom metrics to exometer.
• Only referred to in riak_repl.app.src.
• There appears to be a complicating issue with riak_repl stats in that it is directly referring to folsom, and the latest release of exometer_core removes folsom (as well as bear).
• Is the migration from folsom partial, managed in riak_kv but not in riak_repl?

[Bob-The-Marauder]

I've asked internally and as far as I know, the only potential candidate we have for retention is the riak_core_bg_manager for a little relief for overstressed systems. Even then, it is rarely used.

Possibly add dtrace to the list of items for removal as well?

[martinsumner]

There is also clique. Clique was a framework for doing CLI commands, that is used for a subset of the CLI via the riak_core_console:command/1 function

https://github.com/OpenRiak/riak/blob/openriak-3.2/rel/files/riak-admin#L318-L331
https://github.com/OpenRiak/riak/blob/openriak-3.2/rel/files/riak-admin#L984-L994

Other parts of the CLI do not use clique. The riak_kv_console doesn't appear to use it all. Not sure what the history was here - was clique introduced with the intention of migrating all the CLI over to clique, and that only partially progressed?

Should new extensions to the CLI use clique? What additional capability does clique provide? Perhaps clique should just be removed, and the CLI reverted back to "legacy" methods? Are there other Erlang tools that would now better achieve the same goal?

[aef-]

I think the plan was to migrate over to Clique. It's easier to manage than the shell scripts. Unless there's an alternative we should continue to use Clique and perhaps pare it down. argparse is now in OTP 26 which would cut out a decent amount of Clique. We'll still need the stdout formatter/writers. There's also a hard dependency on Cuttlefish to access/manipulate the config which we could splinter/deprecate? as this prevents most users from adopting Clique.

As for alternatives, I think VerneMQ still uses Clique and EQMX/RabbitMQ have their own solution.

[martinsumner]

Some further information on the gen_nb_server. It appears that previous users, such as RabbitMQ no longer use it.

I've struggled to understand what the original purpose is, but I think this is the nub of it:

https://github.com/erlang/otp/blob/c0ada580e214e3564769371d1978d272a2c39604/erts/preloaded/src/prim_inet.erl#L466-L486

In the OTP code, the calls to the accept function will all lead to a call to async_accept - but this will immediately enter a receive loop for the inet_async message.

The gen_nb_server calls the undocumented function async_accept direct, but doesn't immediately receive - it returns to its gen_server loop, and handles the inet_async message under handle_info/2.

Perhaps there are some advantages here so that other connections are not delayed while one connection sets up.

Ultimately, this feels like a job for ranch. Riak is already using ranch in different places. RabbitMQ uses ranch, Cowboy uses ranch. If we want to scale up the accepting and handling of connections - then ranch seems like a better option.