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
[RFR][MINOR] Use Env Variable to configure Max Listeners at runtime #939
[RFR][MINOR] Use Env Variable to configure Max Listeners at runtime #939
Conversation
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
👍 Bumpy ! |
@slnode ok to test |
@chrisamoore thank you for the pull request. I am not comfortable reading ENV variables so deep inside loopback code. A much cleaner approach is to expose API allowing LoopBack apps to set the MaxListener limit, and then optionally set this limit from ENV in loopback-boot. Depending on your use cases, I can imagine different options for such API:
Implementation: // in lib/model-builder.js
events.setMaxListeners(ModelClass.settings.maxEventListeners || 32); Usage:
Implementation: // in juggler's lib/model-builder.js
events.setMaxListeners(this.maxModelEventListeners || 32);
// in loopback-boot
if (process.env.LB_MAX_LISTENERS) {
app.registry.modelBuilder.maxModelEventListeners = +process.env.LB_MAX_LISTENERS;
} @chrisamoore @raymondfeng thoughts? |
The issue with the static nature of the model config is that it is always at that limit, where as with the ENV flag I can toggle it very simply for tests (which is bombing, and on an older project it kept bombing out due to the monolithic nature of the application) For my particular use case this is only for the nature of the tests we are writing which are exhaustive in nature. cc @bajtos |
I'd also like to see this in model-config instead of as a env variable. Maybe a happy medium would be model-config with a env variable global override? |
@bajtos @BerkeleyTrue Shall I amend the PR to reflect the comment of @BerkeleyTrue above ? |
Also @bajtos the build looks a little funky in it's failures |
Let me summarize my understanding. In @chrisamoore's use case, one wants to set a single flag in a single place to change the @BerkeleyTrue would like to change this value on per-model basis.
Providing a setting at the model level with an option to override the value globally is fine with me. However, I am still opposed to control this directly via ENV variables here in juggler. As I wrote in #939 (comment), the global setting should be kept in BTW I created a new issue to keep track of the requirement to configure For this pull request, I am proposing the following:
This will allow @chrisamoore to handle
Once strongloop/loopback#2370 is landed, one can configure max listeners e.g. this way: // server/config.js
{
"restApiRoot": "/api",
// ...
"modelBuilder": {
"maxModelEventListeners": "${MAX_LISTENERS}"
}
} or alternatively, assuming tests are run with // server/config.test.js
{
"modelBuilder": {
"maxModelEventListeners": 256
}
} (Note that I am assuming the tests are loading the app by importing whole
|
@bajtos would this need to include a PR to loopback as well to affect the |
I don't think so. For short-term, users of this new feature should edit their Both ways, there is no need to change loopback now, this pull request can be landed on its own. |
@chrisamoore ping, what's the status of this patch? Are you still keen to get it finished? |
I am closing this pull request as abandoned. If there is anybody willing to take over this work, then feel free to send a new pull request. See #939 (comment) for guidance. |
@bajtos @raymondfeng please review, simple configuration option to solve, (keeps your hard coded limits, but if I want to push the limits in test scenarios or architecture I should be able to ):