[5.0] more robust chain_api_plugin check in producer_plugin
#2106
Conversation
| ilog("chain_api_plugin configured, defaulting read-only-threads to ${t}", ("t", _ro_thread_pool_size)); | ||
| } | ||
| //appbase initializes configured plugins before auto-start plugins, so if chain_api_plugin is enabled it's | ||
| // initialized before producer_plugin (i.e. before this code here) |
There was a problem hiding this comment.
| if (app().get_plugin("eosio::chain_api_plugin").get_state() == abstract_plugin::initialized) { | ||
| // default to 3 threads for non producer nodes running chain_api_plugin if not specified | ||
| _ro_thread_pool_size = 3; | ||
| ilog("chain_api_plugin configured, defaulting read-only-threads to ${t}", ("t", _ro_thread_pool_size)); |
There was a problem hiding this comment.
Another approach would have been to change the previous check from == to find(), but I like asking appbase more directly instead of fishing in config items that this plugin doesn't "own".
The downside is that the check is reliant on plugin initialization ordering semantics that are arguably an implementation detail of appbase, and that producer_plugin will always remain an auto-start plugin. (Not for 5.0 but possibly in main) appbase might should have a new plugin state: enabled, and all plugins get marked enabled before they get initalize()ed, to avoid this dependency on ordering. (It's possible this isn't a plugin state() but rather some other new is_enabled() property on the plugin)
There was a problem hiding this comment.
How about adding (producer_plugin) to APPBASE_PLUGIN_REQUIRES((chain_plugin)(http_plugin)) of chain_api_plugin.hpp.
There was a problem hiding this comment.
That would require adding producer_plugin as a build dependency of chain_api_plugin -- target_link_libraries() etc. kinda gnarly when they really don't depend on each other.
Maybe need: |
|
bummer I was hoping to avoid that mouthful |
|
Note:start |
Make this check more robust to handle the esoteric config pattern in #2104
Tests needed?