move --plugins from application to binary #1427 #1437

oxarbitrage · 2018-11-15T21:13:11Z

I am sorry to have to open a new pull request for this ...

Related pulls and history are in: #1427 and #1431

In this one i used the commits from @nathanhourt but moved the plugin option to the executable as suggested by #1431 (comment)

In witness_node/main.cpp all plugins need to be registered: https://github.com/oxarbitrage/bitshares-core/blob/f5031bde96c5f3e20fc71c1d34a519bb417e850d/programs/witness_node/main.cpp#L74-L82 but only the ones from the command line will be enabled: https://github.com/oxarbitrage/bitshares-core/blob/f5031bde96c5f3e20fc71c1d34a519bb417e850d/programs/witness_node/main.cpp#L110 or the default ones: https://github.com/oxarbitrage/bitshares-core/blob/f5031bde96c5f3e20fc71c1d34a519bb417e850d/programs/witness_node/main.cpp#L115-L118

This will at least remove the hardcoded plugins from the application.

I was not able to use register_plugin<>(true) here as they all need to be registered before parsing the command line but only some enabled after it, however i did not removed the option as there is probably a workaround for my code there that can make it simpler by the use of that.

Another thing changed is enable_plugin() member from private to public to be called by the executable.

Let me know what do you guys think as if we go with this approach i will need to do something similar in delayed node.

A few things i also noticed while working on this and related are, probably to consider as new issues:

Some plugins(snapshot, witness) add some log msg to the console when they start so you can know they are loaded, others don't do this so you actually dont know from the console if they were loaded or not. I think we should do something for that.
The options you add to the command line are ignored in the config file created, for example if you call the node with witness_node --someoption true, then someoption should be the only line not commented in the config file however this is not the case, it loads the default options. Same behaviour without this pull request(not related to this changes).

As far as I can tell, there was no way previously for an application to register a plugin and ensure that plugin got loaded -- it would be necessary to manually edit the config and specify the plugin be loaded. This is suboptimal; if third party code wishes to track third party extensions on the blockchain, the correct way to do this is with a plugin, and this third party build should be able to load these required plugins regardless of whether the config lists them or not. This commit adds a boolean parameter to application::register_plugin which defaults to false for backwards compatibility; however, if set to true, the plugin will automatically be enabled when the app initializes.

That code was nasty and... kinda wrong. So fix it up all shiny-like. But I also removed the super annoying default "wanted" plugins list, which only causes problems for third parties like me, and in general is just poor form. In my opinion, 5220425 provides a much cleaner way to do this, in a way that is friendly rather than hostile to third parties. Would Be Nice: A generalized plugin conflict system added at the abstract_plugin level, so, for example, the elasticsearch plugin can conflict account_history and we deal with this in a general fashion rather than having this dirty special case check here.

…tshares-core into pull1427_2

oxarbitrage · 2018-11-15T21:56:09Z

Found usage to Nathan true flag to fix the cli_test: adef6a2

pmconrad · 2018-11-17T10:15:04Z

programs/witness_node/main.cpp

+             }
+         });
+      }
+      else {


Perhaps remove this else block and set a default value in line 70 instead?

nice one, added at ce35a79

pmconrad · 2018-11-17T10:31:47Z

So the cli_test crashes were caused by API calls on uninitialized plugins?
We should make sure that such APIs are not accessible.

pmconrad · 2018-11-17T10:33:20Z

The options you add to the command line are ignored in the config file created, for example if you call the node with witness_node --someoption true, then someoption should be the only line not commented in the config file however this is not the case, it loads the default options. Same behaviour without this pull request(not related to this changes).

IMO the current behaviour is reasonable. The config file contains the usual defaults, and the option given on the command line overrides the config file.

pmconrad · 2018-11-18T09:23:26Z

programs/witness_node/main.cpp

      }

+      if (options.count("plugins")) {


Hm, isn't this always true now that the option has a default value?

sorry about that, you are right, fixed at 58ad814

pmconrad · 2018-11-18T14:28:36Z

Looks good. @nathanhourt what do you think? Does that satisfy your requirements?

nathanielhourt · 2018-11-27T21:37:36Z

Yep, this looks reasonable to me.

abitmore · 2018-11-28T13:09:28Z

Please update title of this PR to clearer. It's annoying to have to click to another issue/PR to see what this PR is about.

abitmore · 2018-11-29T21:31:16Z

This will break the standalone delayed_node binary, no?

@abitmore

@abitmore you're right.

pmconrad · 2018-11-30T17:30:26Z

delayed_node compiles and runs but doesn't activate the delayed_node plugin. :-/

@oxarbitrage please adapt delayed_node/main.cpp in the same way.

nathanielhourt · 2018-12-04T20:42:01Z

programs/delayed_node/main.cpp

-      auto delayed_plug = node.register_plugin<delayed_node::delayed_node_plugin>();
-      auto history_plug = node.register_plugin<account_history::account_history_plugin>();
-      auto market_history_plug = node.register_plugin<market_history::market_history_plugin>();
+      auto delayed_plug = node->register_plugin<delayed_node::delayed_node_plugin>();


Perhaps auto delayed_plug = node->register_plugin<delayed_node::delayed_node_plugin>(true);?

make sense in this context, added. thanks.

pmconrad · 2018-12-14T13:19:32Z

programs/delayed_node/main.cpp

@@ -60,7 +60,7 @@ fc::optional<fc::logging_config> load_logging_config_from_ini_file(const fc::pat

 int main(int argc, char** argv) {
   try {
-      app::application node;
+      app::application* node = new app::application();


Why? Now you have to delete it when you're done.

i actually changed that because of this:

(gdb) r Starting program: /home/alfredo/CLionProjects/pull1427_2/programs/delayed_node/delayed_node [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 2133844ms th_a main.cpp:109 main ] Writing new config file at /home/alfredo/CLionProjects/pull1427_2/delayed_node_data_dir/config.ini Program received signal SIGSEGV, Segmentation fault. 0x0000555557889fdd in graphene::chain::database::close (this=0x55555b83ab70, rewind=true) at /home/alfredo/CLionProjects/pull1427_2/libraries/chain/db_management.cpp:222 222 uint32_t cutoff = get_dynamic_global_properties().last_irreversible_block_num; (gdb) bt #0 0x0000555557889fdd in graphene::chain::database::close (this=0x55555b83ab70, rewind=true) at /home/alfredo/CLionProjects/pull1427_2/libraries/chain/db_management.cpp:222 #1 0x0000555557240b11 in graphene::app::application::~application (this=0x7fffffffda00, __in_chrg=<optimized out>) at /home/alfredo/CLionProjects/pull1427_2/libraries/app/application.cpp:926 #2 0x0000555557003387 in main (argc=1, argv=0x7fffffffde48) at /home/alfredo/CLionProjects/pull1427_2/programs/delayed_node/main.cpp:63 (gdb)

Hm, the destructor generates a SIGSEGV and the solution is to avoid calling the destructor? That's evil.
Does the crash also happen without your other changes? If so, this should be kept as-is and fixed properly in another issue. If not you should find the root cause and fix it properly now.

pmconrad · 2018-12-14T13:22:59Z

programs/delayed_node/main.cpp

@@ -160,26 +167,24 @@ int main(int argc, char** argv) {
         elog("Error parsing configuration file: ${e}", ("e", e.what()));
         return 1;
      }
-      if( !options.count("plugins") )


You should keep the "plugins" option. We don't want to change the behaviour of the executable.

this is done 1326a5c

oxarbitrage · 2018-12-15T16:24:27Z

In a branch i have handy here based on hardfork without any of the changes:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$ ./programs/delayed_node/delayed_node 
Segmentation fault (core dumped)
alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$

I didn't know the issue was unrelated to the changes done here until now.

So i did it the way the witness_node binary is done but without deleting. What do you think if we add:

bitshares-core/programs/witness_node/main.cpp

Lines 164 to 181 in ce35a79

    
              int signal = exit_promise->wait(); 
        
              ilog("Exiting from signal ${n}", ("n", signal)); 
        
              node->shutdown_plugins(); 
        
              node->shutdown(); 
        
              delete node; 
        
              return 0; 
        
           } catch( const fc::exception& e ) { 
        
              // deleting the node can yield, so do this outside the exception handler 
        
              unhandled_exception = e; 
        
           } 
        
           if (unhandled_exception) 
        
           { 
        
              elog("Exiting with error:\n${e}", ("e", unhandled_exception->to_detail_string())); 
        
              node->shutdown(); 
        
              delete node; 
        
              return 1; 
        
           }

in this pull to fix it ?

pmconrad · 2018-12-16T09:35:37Z

Yes, if that works.
Note that shutdown may be called twice here (same is true in witness_node). But that's an unrelated issue.

oxarbitrage · 2018-12-17T14:01:31Z

@pmconrad by going more into this i decided to reverse most of the changes done in the delayed node and just make the delayed node plugin to be loaded correctly into the binary. a8020a7

The delayed node haves several issues that are unrelated to the scope of this pull request, for example:

plugins option will not work:

in this patch output will be:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$ ./programs/delayed_node/delayed_node --plugins "whatever"
Error parsing command line: unrecognised option '--plugins'
Segmentation fault (core dumped)
alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$

in unpatched node:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$ ./programs/delayed_node/delayed_node --plugins "whatever"
Segmentation fault (core dumped)
alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$

when required trusted node option is needed:

with this pull:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$ ./programs/delayed_node/delayed_node
Segmentation fault (core dumped)
alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$

without it:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$ ./programs/delayed_node/delayed_node
Segmentation fault (core dumped)
alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$

this will work in both versions, this is what really matters:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$ ./programs/delayed_node/delayed_node --trusted-node "127.0.0.1:8090"
3331840ms th_a       main.cpp:109                  main                 ] Writing new config file at /home/alfredo/CLionProjects/pull1427_2/delayed_node_data_dir/config.ini
3331845ms th_a       db_management.cpp:174         open                 ] Wiping object_database due to missing or wrong version
3331845ms th_a       object_database.cpp:93        wipe                 ] Wiping object database...
3331845ms th_a       object_database.cpp:95        wipe                 ] Done wiping object databse.
3331845ms th_a       object_database.cpp:106       open                 ] Opening object database from /home/alfredo/CLionProjects/pull1427_2/delayed_node_data_dir/blockchain ...
3331845ms th_a       object_database.cpp:111       open                 ] Done opening object database.
3331847ms th_a       application.cpp:325           operator()           ] Initializing database...
...

version without patch:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1324_3$ ./programs/delayed_node/delayed_node --trusted-node "127.0.0.1:8090"
3278444ms th_a       db_management.cpp:174         open                 ] Wiping object_database due to missing or wrong version
3278444ms th_a       object_database.cpp:93        wipe                 ] Wiping object database...
3278444ms th_a       object_database.cpp:95        wipe                 ] Done wiping object databse.
3278445ms th_a       object_database.cpp:106       open                 ] Opening object database from /home/alfredo/CLionProjects/pull1324_3/delayed_node_data_dir/blockchain ...
3278453ms th_a       object_database.cpp:111       open                 ] Done opening object database.
3278454ms th_a       application.cpp:325           operator()           ] Initializing database...

delayed node uses old config functions that are now in config_utils.cpp.
etc.

Much of this is unrelated to the scope of this pull(which is already pretty big) so we better treat them somewhere else as you suggested, the important thing to me is that now the delayed node binary of this pull works the same(with the same problems) as the delayed node before.

oxarbitrage · 2018-12-17T14:21:18Z

There is another case where the unpatched version was working ok while the patched failing.

It is the case when --plugins option is used with 1 of the 3 allowed plugins from the delayed binary(delayed_node account_history market_history).

With 1326a5c both versions will do the same. For example user will want to load delayed node and market history plugin leaving account history out, he can do that now in the patched version.

jmjatlanta · 2018-12-28T18:55:49Z

These changes look good. I see one comment above that I am unsure that it has been handled. Perhaps it has, but I do not see it.

We should make sure that such APIs are not accessible.

If it has been handled, great. If not, what would be the expected behavior? An exception stating that the function is not available? Or perhaps you cannot even get a pointer to that API to be able to call that function?

pmconrad · 2019-01-02T16:18:31Z

programs/delayed_node/main.cpp

+      std::set<std::string> plugins;
+      boost::split(plugins, options.at("plugins").as<std::string>(), [](char c){return c == ' ';});
+
+      if(plugins.count("account_history") && plugins.count("elasticsearch")) {


This check is useless. Elasticsearch is not available in delayed_node.

pmconrad · 2019-01-17T13:33:29Z

libraries/plugins/delayed_node/delayed_node_plugin.cpp

@@ -58,7 +58,7 @@ delayed_node_plugin::~delayed_node_plugin()
 void delayed_node_plugin::plugin_set_program_options(bpo::options_description& cli, bpo::options_description& cfg)
 {
   cli.add_options()
-         ("trusted-node", boost::program_options::value<std::string>(), "RPC endpoint of a trusted validating node (required for delayed_node)")
+         ("trusted-node", boost::program_options::value<std::string>()->default_value("127.0.0.1:8090"), "RPC endpoint of a trusted validating node (required for delayed_node)")


This is probably a bad default because that's usually the port where the node itself will be listening. IMO it's better to leave this option without a default. Users should have to actively choose which node they trust.

I changed it back at e198552

I added it because the binary seg faults when starting with no option:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$ ./programs/delayed_node/delayed_node Segmentation fault (core dumped) alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$

It need to be started with trusted node option:

alfredo@alfredo-System-Product-Name:~/CLionProjects/pull1427_2$ ./programs/delayed_node/delayed_node --trusted-node "127.0.0.1:8090" 2348175ms th_a main.cpp:111 main ] Writing new config file at /home/alfredo/CLionProjects/pull1427_2/delayed_node_data_dir/config.ini 2348180ms th_a db_management.cpp:174 open ] Wiping object_database due to missing or wrong version 2348180ms th_a object_database.cpp:93 wipe ] Wiping object database... 2348180ms th_a object_database.cpp:95 wipe ] Done wiping object databse.

This problem is independent from the changes in this pull request. Another example of segfault in the delayed_node binary can be observed at the end of the output from ./delayed_node --help

As a workaround i tried: app::application* node = new app::application(); before but was later discarded.

I think we can address this issue in a separate pull request in order to dont complicate things too much further.

Let me know what do you think, thanks again.

The segfault will be fixed with #1529. It happens because the delayed_node plugin complains about the missing option and then tries to close a database that has never been opened.

great, thanks.

pmconrad · 2019-01-20T15:07:43Z

Good to go now IMO, thanks!

oxarbitrage · 2019-01-20T15:34:39Z

thanks @pmconrad merging now.

nathanielhourt and others added 5 commits November 9, 2018 14:54

Merge commit 'refs/pull/1427/head' of https://github.com/bitshares/bi…

3e683ed

…tshares-core into pull1427_2

move plugins option to witness_node executable

f5031bd

fix cli wallet test

adef6a2

remove double space line

9647ad1

pmconrad reviewed Nov 17, 2018

View reviewed changes

add default plugin values to option

ce35a79

pmconrad reviewed Nov 18, 2018

View reviewed changes

remove not needed check

58ad814

This was referenced Nov 27, 2018

Improve plugin loader #1427

Closed

a possible replacement for #1427 #1431

Closed

oxarbitrage changed the title ~~Another one for pull #1427~~ move --plugins from application to binary #1427 Nov 28, 2018

pmconrad previously approved these changes Nov 29, 2018

View reviewed changes

fix delayed node

7089d2a

nathanielhourt reviewed Dec 4, 2018

View reviewed changes

use auto load plugins in delayed node

1dd719f

pmconrad reviewed Dec 14, 2018

View reviewed changes

pmconrad suggested changes Dec 14, 2018

View reviewed changes

reverse delayed node and only add auto to needed plugins

a8020a7

make plugins option work in delayed

1326a5c

pmconrad reviewed Jan 2, 2019

View reviewed changes

oxarbitrage added 3 commits January 16, 2019 10:58

remove useless check

a590c25

add default value to trusted-node

caf7f7f

Merge branch 'develop' into pull1427_2

bac55a4

pmconrad reviewed Jan 17, 2019

View reviewed changes

remove default option in delayed plugin

e198552

pmconrad approved these changes Jan 20, 2019

View reviewed changes

oxarbitrage merged commit bbcbed0 into bitshares:develop Jan 20, 2019

abitmore added this to the 201901 - Feature Release milestone Jan 20, 2019

MichelSantos mentioned this pull request Feb 7, 2019

Release Notes for the 201902 Feature Release of BitShares Core #1565

Closed

pmconrad mentioned this pull request Mar 7, 2019

"plugins" option in config.ini is ignored #1637

Closed

17 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

move --plugins from application to binary #1427 #1437

move --plugins from application to binary #1427 #1437

oxarbitrage commented Nov 15, 2018

oxarbitrage commented Nov 15, 2018

pmconrad Nov 17, 2018

oxarbitrage Nov 17, 2018

pmconrad commented Nov 17, 2018

pmconrad commented Nov 17, 2018

pmconrad Nov 18, 2018

oxarbitrage Nov 18, 2018

pmconrad commented Nov 18, 2018

nathanielhourt commented Nov 27, 2018

abitmore commented Nov 28, 2018

abitmore commented Nov 29, 2018

pmconrad commented Nov 30, 2018

nathanielhourt Dec 4, 2018

oxarbitrage Dec 5, 2018

pmconrad Dec 14, 2018

oxarbitrage Dec 14, 2018

pmconrad Dec 15, 2018

pmconrad Dec 14, 2018

oxarbitrage Dec 28, 2018

oxarbitrage commented Dec 15, 2018

pmconrad commented Dec 16, 2018

oxarbitrage commented Dec 17, 2018

oxarbitrage commented Dec 17, 2018

jmjatlanta commented Dec 28, 2018

pmconrad Jan 2, 2019

pmconrad Jan 17, 2019

oxarbitrage Jan 17, 2019

pmconrad Jan 20, 2019

oxarbitrage Jan 20, 2019

pmconrad commented Jan 20, 2019

oxarbitrage commented Jan 20, 2019

move --plugins from application to binary #1427 #1437

move --plugins from application to binary #1427 #1437

Conversation

oxarbitrage commented Nov 15, 2018

oxarbitrage commented Nov 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmconrad commented Nov 17, 2018

pmconrad commented Nov 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmconrad commented Nov 18, 2018

nathanielhourt commented Nov 27, 2018

abitmore commented Nov 28, 2018

abitmore commented Nov 29, 2018

pmconrad commented Nov 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oxarbitrage commented Dec 15, 2018

pmconrad commented Dec 16, 2018

oxarbitrage commented Dec 17, 2018

oxarbitrage commented Dec 17, 2018

jmjatlanta commented Dec 28, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmconrad commented Jan 20, 2019

oxarbitrage commented Jan 20, 2019