-
Notifications
You must be signed in to change notification settings - Fork 18
Update troubleshooting.mdx #576
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
base: master
Are you sure you want to change the base?
Conversation
Deploying configcat-docs with
|
Latest commit: |
c11d472
|
Status: | ✅ Deploy successful! |
Preview URL: | https://1e20e10f.docs-xmy.pages.dev |
Branch Preview URL: | https://aisz0811-patch-8.docs-xmy.pages.dev |
1. Singleton: We strongly recommend using the ConfigCat SDK as a Singleton. Initializing the SDK over and over again can cause serious performance issues in production. If you want to use multiple SDK Keys in the same application, create only one _ConfigCat Client_ per SDK Key. | ||
1. Make sure you're using the latest version of the ConfigCat SDK. | ||
1. Check if you've configured the [Data Governance](../advanced/data-governance.mdx) functionality correctly. | ||
1. Singleton: We strongly recommend using the ConfigCat SDK as a singleton. Initializing the SDK multiple times can cause serious performance issues in production. If you need to use multiple SDK Keys in the same application, create only one _ConfigCat Client_ per SDK Key. |
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.
Maybe we can simply remove this part as this issue has been solved in the SDKs for years now. I mean it's not possible to create multiple client instances for the same SDK Key. @laliconfigcat What do you think?
1. Singleton: We strongly recommend using the ConfigCat SDK as a singleton. Initializing the SDK multiple times can cause serious performance issues in production. If you need to use multiple SDK Keys in the same application, create only one _ConfigCat Client_ per SDK Key. |
1. Are you using the proper polling mode for your use case? Details on polling modes in the [SDK Docs](../sdk-reference/overview.mdx). | ||
1. Might be a too frequent `Auto Polling` interval. Please check the [SDK Docs](../sdk-reference/overview.mdx). | ||
1. Your `Auto Polling` interval might be too frequent Please check the [SDK Docs](../sdk-reference/overview.mdx). |
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 suggest rephrasing this to be consistent with the other points. Plus, it might be worth mentioning the consequences.
1. Your `Auto Polling` interval might be too frequent Please check the [SDK Docs](../sdk-reference/overview.mdx). | |
1. Are you using the right polling interval for `Auto Polling`? Too frequent polling will increase your network traffic. Please check the [SDK Docs](../sdk-reference/overview.mdx). |
1. Are you using the proper polling mode for your use case? Details on polling modes in the [SDK Docs](../sdk-reference/overview.mdx). | ||
1. Might be a too frequent `Auto Polling` interval. Please check the [SDK Docs](../sdk-reference/overview.mdx). | ||
1. Your `Auto Polling` interval might be too frequent Please check the [SDK Docs](../sdk-reference/overview.mdx). | ||
1. In `Manual Polling` mode, it could be a too frequent `forceRefresh()` call in your code, making the SDK download the config JSON often. |
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.
1. In `Manual Polling` mode, it could be a too frequent `forceRefresh()` call in your code, making the SDK download the config JSON often. | |
1. In `Manual Polling` mode, are you calling `forceRefresh()` in your code as frequently as needed? Excessive refreshes will increase your network traffic. |
1. You might need to whitelist the following addresses in your firewall: `cdn.configcat.com`, `cdn-eu.configcat.com`, `cdn-global.configcat.com`. | ||
|
||
--- | ||
|
||
## Too many requests error in Angular | ||
|
||
The problem was caused by Angular's Hot Module Replacement functionality during development. The wrapper class, which contained the auto polling ConfigCat SDK was edited, and the Hot Module Replacement reinitialized the whole class without releasing the old, replaced module's Auto Polling timer. | ||
We believe that this is a really rare case, it could happen only during development. | ||
This issue can occure due to Angular's Hot Module Replacement functionality during development. The wrapper class containing the Auto Polling ConfigCat SDK is edited, the Hot Module Replacement can reinitialize the whole class without releasing the old, replaced module's Auto Polling timer. |
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.
Got pretty incoherent, needs improvement.
BTW, @laliconfigcat, is this still a relevant issue?
This issue can occure due to Angular's Hot Module Replacement functionality during development. The wrapper class containing the Auto Polling ConfigCat SDK is edited, the Hot Module Replacement can reinitialize the whole class without releasing the old, replaced module's Auto Polling timer. | |
This issue can occur due to Angular's Hot Module Replacement functionality during development when you have a class that wraps the ConfigCat SDK running in Auto Polling mode and the wrapper class is edited. The Hot Module Replacement may reinitialize the whole class without stopping the ConfigCat SDK's Auto Polling timer in the old, replaced module. |
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 think it is relevant, but i didn't try it.
The problem was caused by Angular's Hot Module Replacement functionality during development. The wrapper class, which contained the auto polling ConfigCat SDK was edited, and the Hot Module Replacement reinitialized the whole class without releasing the old, replaced module's Auto Polling timer. | ||
We believe that this is a really rare case, it could happen only during development. | ||
This issue can occure due to Angular's Hot Module Replacement functionality during development. The wrapper class containing the Auto Polling ConfigCat SDK is edited, the Hot Module Replacement can reinitialize the whole class without releasing the old, replaced module's Auto Polling timer. | ||
We believe that this is a rare edge case that only happens during development. |
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.
We believe that this is a rare edge case that only happens during development. | |
We consider this a rare edge case that only happens during development. |
Describe the purpose of your pull request
Related issues (only if applicable)
How to test? (only if applicable)
Requirement checklist