-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Unused threads and thread pools in kubernetes.watch.Watch._api_client #545
Comments
Workaround that kills some threads right after the Watch object is constructed: watch = kubernetes.watch.Watch()
watch._api_client.pool.close()
watch._api_client.rest_client.pool_manager.clear() |
This is a bug in the upstream swagger-codegen project fixed by swagger-api/swagger-codegen#8061 . Once that is merged, re-rendering with the updated swagger-codegen should fix it. |
Is there any update to this? I am also trying to use many watches simultaneously and its hogging a lot of memory. Any advise to make a client(capable of setting up watches and digesting the events) really scalable in the most efficient manner. |
@bidyut1990 which version do you use? It should be fixed in v9.0.0. If you need to handle many watches in your application you may be interested asynchronous fork of this library kubernetes-asyncio. |
@tomplus - I am using 9.0.0 only but i did not realize it's been fixed. Anyways, i ll also take a look at the async based package. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@bidyut1990 could you please verify if the fix works? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
TL;DR every Watch object consumes 16 threads for no apparent reason
kubernetes.watch.Watch
creates an APIClient in its constructor:Which is only used for
deserialize
purposes, not for making calls:The problem is that
ApiClient
is a rather expensive object that creates a newThreadPool
andRESTClientObject
every time:The
RESTClientObject
is default-constructed (noconfiguration
), which implies:and
The text was updated successfully, but these errors were encountered: