-
Notifications
You must be signed in to change notification settings - Fork 11
Connection Pool reset, due to connection parameters change, during operation #66
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
Open
joaoroscoe
wants to merge
5
commits into
alexandrainst:main
Choose a base branch
from
joaoroscoe:pool_reset
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
a77cb94
Reset db connection on message reception, if needed (new config data)
4330fcd
Move back connection pool object into configuration node
c1d192f
Fix linter findings
3125035
Simplify changes check (don't need full objects comparison)
f817ebe
Monitor changes to flagged parameters, only; support "reconnect in msg
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
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.
This code introduces quite some overhead and therefore some performances penalties. This is on the "hot path", and will be called many many times. So we need to be careful and see how the negative consequences can be mitigated
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 just realized that the fact that this will run at all messages reception could become a real problem depending on the scenario considered. Quite simplistic, my initial idea, sorry!
In my specific scenario, the frequency of transactions in the database is relatively low, so I am unlikely to face performance issues, here. However, of course, we want a solution that is scalable.
Possibilities that occur to me:
Answering your question: in my specific scenario, only the database access password, which is obtained from an external system, will be changed periodically, as part of a security policy.
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.
There is another potential issue: considering that we could have several nodes acessing the database, what would happen if a node restarts the pool, and another one is caught right in the middle of trying to use it ?
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.
Those are all good ideas. Exposing a possibility to reload the pool, for instance through a specific message, could be a simple option. Please check my question further down, so I can better understand the use case.
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.
Regarding concurrency, that will need to be tested when we have some a clearer scenario
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.
Have just pushed a new commit, including:
Inputs (checkboxes) were added to the configuration node editor, to flag the connection parameters to be monitored for changes. Those are read at initialization, and pushed into a "watch list" array. Only parameters on that list will be checked at message reception, greatly minimizing overhead in the "hot path".
Additionally, I made changes in node-config-input-ssl input html definition, so that the Typed Input widget will show with the same width as the other ones, to make space for 'global' type input.
I haven't touched the documentation, so far.
Your tougths ?