-
Notifications
You must be signed in to change notification settings - Fork 2
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
High increase in memory consumption & thread count when updated to the 1.9.0
version
#52
Comments
thanks for raising the issue, we are looking into it. @ondrejfuhrer |
Hey @ishaileshmishra any update on this? It's more then a month without any update 😞 |
Hi @ondrejfuhrer, We have made some changes in the code that might be helpful for you. We are in the process to release a newer version of dependency by next week |
Hi @ishaileshmishra, it looks like there is no new release yet. Can you provide us any updates on this? Thanks. |
- High memory consumption, proxy, and LivePreview ✔️ - pom.xml transitive vulnerability removed 🐞 - #52 issue fixed 🐛
Hi @vitorsdcs @ondrejfuhrer, Please update the SDK to v1.10.0 and let us know if it solved the issue. |
Hey @ishaileshmishra , thank you for that. Created a different issue with |
Hey @ishaileshmishra , just wanted to let you know, that it seems all the issues we had with the latest release are fixed and looking great. Thank you for your support 🙂 |
- High memory consumption, proxy, and LivePreview ✔️ - pom.xml transitive vulnerability removed 🐞 - #52 issue fixed 🐛
Hello team,
We’re currently running version
1.7.0
of your SDK without any issues. We tried to upgrade to the newest version this week, however after deploying the version we could see immediately a high increase on opened threads & increased memory usage for each running pod. Here you can see the reported avg thread count for the deployed period (14:55 we started rolling out the version1.9.0
, at around 15:12 we started rolling out the previous version).At the same time memory consumption of each pod went approx. 50% up (I mean, needs to handle all the active threads etc), which leads me to an assumption that we might be facing some sort of resource leak in the library. Or is that something expected from your end? It’s hard to correlate any changelog items to this.
Also worth mentioning: We also tested other versions and it seems to have the same issues, so the issue was probably introduced in the version
1.8.0
.The text was updated successfully, but these errors were encountered: