feat(ConnectionPools): added connection pools class #85
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding connection pools capability, but will add the actual pools
to Storage when other PRs are merged first.
In an earlier iteration the ConnectionPool capped the number of connections that could be outstanding. However, after some more usage, it became apparent that there were threading issues.
I tried to write a thread safe version that was inspired by urlib3.HTTPConnectionPool, but it turned out that it was quite difficult to perform 'queue.put(block=True)' and accurately count the number of outstanding connections without triggering a deadlock.
e.g.
The new philosophy is that in reality a substantial number of connections can remain open without ill effects (dozens or hundreds), the important thing is to allow them to be reused, which will substantially slow their growth, maybe completely depending on how the code is written. Thus this version of
ConnectionPool
is thread safe, but does not cap the number of outstanding connections.Testing Sufficiency Declaration
The pool is stressed in test_connections. A production run in a separate branch seemed to eliminate SSLEOFError that is raised from ssl.c that was probably caused by multithreading issues, and the presence of a pool seemed to reduce the number of handshake errors overall (except for DNS, which is a somewhat separate issue).