Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/es voting stat plugin #1983

Open
wants to merge 18 commits into
base: develop
Choose a base branch
from

Conversation

Dimfred
Copy link

@Dimfred Dimfred commented Sep 7, 2019

Sry for the last PR (#1971), here is now the clean one.

Like said, still not fully mature.

@Dimfred Dimfred force-pushed the feature/es-voting-stat-plugin-clean branch from c214135 to 47861c9 Compare September 7, 2019 10:05
@abitmore abitmore added this to the 4.1.0 - Feature Release milestone Sep 7, 2019
@pmconrad
Copy link
Contributor

pmconrad commented Sep 8, 2019

still not fully mature.

Note that you can create "draft" pull requests.

Copy link
Contributor

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the new plugin affect replay time

  • when turned off?
  • when turned on (without ES-objects plugin)?

libraries/chain/db_maint.cpp Outdated Show resolved Hide resolved
/**
* Emitted after the beginning of the maintenance interval
*/
fc::signal<void(uint32_t)> on_maintenance_begin;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this resolves #211.

/**
* Emitted after the calculation of the voting_stake (occurs in the maintenance interval)
*/
fc::signal<void(const account_object&, const account_object&, const uint64_t)> on_voting_stake_calculated;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, unsure if we want to add such a specific signal. @abitmore @jmjatlanta?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At a glance I don't like it. Is there any way to avoid this?

Copy link
Author

@Dimfred Dimfred Sep 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need all the data to properly feed the plugin, so AFAIK there is no way to avoid this. Everything is performed inside the vote_tally_helper and nothing is given outside.

What exactly do you don't like? Is the signal signature too specific?

To make it more generic I could switch the emission signature to emit an object with the data. This would make it extensible. It would be up to the signal receiver to use the data or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood correctly, void(const account_object&, const account_object&, const uint64_t) means we need to emit the signal once per account, which IMHO is too many. I think it's easier if we add the voting_stake data directly into account_statistics_object as a member variable, although this would need a bit more memory.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right. The signal is emitted once per account.

Inserting data in account_statistics_object would mean double tracking of the data. Also it would then insert always (or make a check whether the plugin is active, but this seems weird IMHO). But the plugin kinda looses its purpose then.

What would be if I gathered the data first and then emit the signal with all the data? This would call the signal only once and wouldn't require more memory to be used. Though still would require a check whether the plugin is active or not.

libraries/plugins/es_objects/es_objects.cpp Show resolved Hide resolved
libraries/protocol/include/graphene/protocol/types.hpp Outdated Show resolved Hide resolved
@@ -52,4 +52,8 @@ target_link_libraries( es_test
graphene_es_objects graphene_egenesis_none graphene_api_helper_indexes
fc ${PLATFORM_SPECIFIC_LIBS} )

file( GLOB VOTING_STAT_SOURCES "voting_stat/*.cpp" )
add_executable( voting_stat_test ${COMMON_SOURCES} ${VOTING_STAT_SOURCES} )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move general tests into normal test suite and ES-specific tests into ES test suite. A separate executable will most likely not be run by developers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay will do that.

@Dimfred Dimfred force-pushed the feature/es-voting-stat-plugin-clean branch from 0f0ad85 to b53b254 Compare September 10, 2019 12:28
_maint_block = block_num;
_create_voteable = true;
}
++_maint_counter;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will not work properly. If there's a fork around the maintenance interval, the counter may be incremented multiple times for a single maintenance interval, and not consistently across all nodes.

Copy link
Author

@Dimfred Dimfred Sep 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm now this is a bit of a problem. But if I would just remove that (ignore the fact that we then can't control the number of objects we track) wouldn't there be the same problem? That different objects will be pushed to es from different nodes?

Is there some form of signal which could be applied on_fork? That would decrement the counter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but you can detect the switch to a fork in applied_block - block numbers should increase strictly monotonically, i. e. if the new block number is the same or lower than the previous you know that the chain is switching to a fork.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay. Understood. Will rebuild that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have still some problems with that. E.g. on_maintenance_begin is called and the plugin routine is performed. Now a fork appears, which leads to another maintenance interval.
AFAIU the plugin routine should now be applied to the fork maintenance.
So when something like that happens I need to revert the changes from the previous interval and apply the plugin routine to the fork interval. Please correct me if I am wrong.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually knowing that the chain is switching to a fork is not enough, because in extreme cases a fork can span more than one maintenance interval.
A catch-all solution would be to store the counter in a database field instead of using an instance variable. Database entries are rolled back automatically when switching to a different fork.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I see. I'll try to figure that out. But in such cases there should also be problems with es_objects plugin I think. For example I have added a forbid_delete_flag which forbids the es_objects delete operation for vote*_objects (so it's possible to delete them in the plugin but still store them in es). Meaning a fork appears, rerolls the objects, which should normally delete them (probably). But this doesn't happen.

But in general I think I understood your solution. I will create a db object which keeps track of the counter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meaning a fork appears, rerolls the objects, which should normally delete them (probably). But this doesn't happen.

Correct. IIRC we decided that it doesn't matter because objects will eventually be overwritten by new objects with the same ID.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah indeed, you are right. Okay then I think I got no further question for now. Thanks for the help.

@Dimfred Dimfred force-pushed the feature/es-voting-stat-plugin-clean branch 3 times, most recently from 5ca7486 to c4a679d Compare October 21, 2019 13:24
@Dimfred Dimfred force-pushed the feature/es-voting-stat-plugin-clean branch from c4a679d to f47e5ba Compare October 21, 2019 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Allow plugins to add tasks to chain maintenance
3 participants