-
Notifications
You must be signed in to change notification settings - Fork 844
Add config option to enable/disable dynamic plugin reload feature #6421
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
Merged
sudheerv
merged 1 commit into
apache:master
from
15ljindal:plugin_dynamic_reload_config_option
Mar 3, 2020
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To increase encapsulation
_dlhwas not exposed on purpose to prevent users from accessing it directly (hiding the implementation details). I still made itprotectedso when we need to test the behavior ofPluginDsoinstances we could inherit from it and expose internals but only for the scope of the unit-test (you have probably already noticed this pattern in the unit-tests)Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same thing in mind originally, but here is my thought process.
First, I feel it is a reasonable assumption to assume that the dso will be opened using dlopen and thus asking for its handle seems reasonable as well.
I looked at how we can use the suggestion of having a class derived from PluginDso where this member can be accessed in unit-tests (file test_PluginFactory.cc), and there does not seem to be an easy way to do that without writing too much bolier-plate code for a small change. I will try to explain here.
There are calls like
RemapPluginInst *plugin_v2 = factory2->getRemapPlugin(configName, 0, nullptr, error2, isPluginDynamicReloadEnabled());which return an object of typeRemapPluginInstwhich holds a pointer to an object of typeRemapPluginInfo. In order to get get access to_dlhwithout thisPluginDso::dlOpenHandle()function, I think I would have to defineclass RemapPluginInfoTest : public RemapPluginInfoand then define copy constructors in classRemapPluginInfoTest,RemapPluginInfoandPluginDso, so that I can do something likeRemapPluginInst *plugin_v2 = factory2->getRemapPlugin(configName, 0, nullptr, error2, isPluginDynamicReloadEnabled());RemapPluginInfoTest test_object(plugin_v2->_plugin);CHECK(test_object._dlh == ...)In short, above seems like an over-kill to me and thus, having this function
PluginDso::dlOpenHandle()seems fine to me. Please let me know if I missed something or if you have any further thoughts.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure why my response does not show up here. Please see - #6421 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Encapsulation can be an obstacle to simplicity but it has its benefits - think in terms of preventing the
PluginDsouser from callingdlclosedirectly, also about possibility to implement internalPluginDsohousekeepingI think it could be expected to have little bit more "cumbersome" unit-test code in the name of better module design. IMHO it does not mean that this is not worth pursuing, it rather means that we have not come up with a better way to do it.
True, access modifiers, design patterns often go in the opposite direction to simplicity (similarly security vs usability) but it is believed that they could help long term. Also sometimes it just seem more complex than it actually is (i.e. removing the coupling in
PluginDsodid not really make the code more complex)Fair enough, I appreciate the thorough unit-tests related to the plugin isolation! I think we are in a good shape here - coverage is good and we can catch regressions in future which is the final goal here.