Move get_info off main thread and run in http thread

[linh2931]

/v1/chain/get_info is a top 1 or 2 used RPC endpoint (AntelopeIO/leap#1212). It is currently processed on the main thread. Moving it off the main thread will reduce load on the main thread, and will shorten response time when the main thread is stuck (#830).

This PR moves get_info off the main thread and runs it on http thread. The data required by get_info is cached on accept_block signal and is used to service get_info when needed.

Notably, the implementation is mutex free such that the main thread is never blocked by get_info.

Resolves #527

[greg7mdp]

I think it could be implemented in a simpler way.

Instead of having the chain_plugin query the controller for all the individual members, why not have the controller allocate a new struct of get_info_results at each accepted_block (using std::make_shared) and, when populated, store the result in controller in a std::atomic<std::shared_ptr>.

Then the chain_plugin can simply get this pointer and use it at each get_info (no mutex necessary).

[linh2931]

Will work on mutex locations tomorrow. Hopefully now all tests can pass without modifying them.

[linh2931]

I think it could be implemented in a simpler way.

Instead of having the chain_plugin query the controller for all the individual members, why not have the controller allocate a new struct of get_info_results at each accepted_block (using std::make_shared) and, when populated, store the result in controller in a std::atomic<std::shared_ptr>.

Then the chain_plugin can simply get this pointer and use it at each get_info (no mutex necessary).

Thanks. New implementation makes it mutex free while doing it in chain_plugin

[greg7mdp]

We agreed that we didn't need that check since chain_api_plugin is most of the time configured.

[linh2931]

It is most likely configured in BP nodes but not necessarily in other nodes.

[greg7mdp]

while doing it in chain_plugin

Why? I think it is better to do it in controller, as it makes the information available to whomever needs it (could be prometheus for example), not just the chain plugin.

[linh2931]

information

I think it is better separate concern doing it in chain_plugin; let controller just emit signals and its users decide what to do with the signals. All the data required by get_info is available with currently controller APIs. There is no need to add another one.

[ericpassmore]

Note:start
category: System Stability
component: Internal
summary: Move get_info off main thread and run in http thread.
Note:end