-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Use a threadpool for async requests #226
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
Comments
@yuvipanda : we are using urllib3.PoolManager, please see https://github.com/kubernetes-client/python-base/blob/7c8e59b58d9a769f1ca3f818aa91c8a6538b51b1/rest.py#L110 |
Aaah, whoops! Didn't notice that - it was doing Thread() last time I looked (was a while ago!). Thanks :) |
I'm actually curious about https://github.com/kubernetes-incubator/client-python/blob/f399ece006d43970a9d25052798782db1407fd05/kubernetes/client/api_client.py#L331 - which starts an entirely new thread for each request still. This is a thread pool, unrelated to the urllib3 connection pool... |
Note: I've started using a threadpool for this in my applications and performance is much better! |
That is a good idea. Would I suggest you contribute it back to |
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. |
…_work fix: load cache error when CacheDecoder object is not callable
Currently, a new thread is created for each HTTP request. Would be nicer to have the option of using a ThreadPool with a ThreadPoolExecutor instead.
We can already wrap this ourselves when using, but would be nice to do this in the library itself so async usage is cleaner
The text was updated successfully, but these errors were encountered: