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
Pool Depletion / Leaking Connections #76
Comments
Ah, thank you for the excellent bug report and analysis. I believe you're correct. Is this something you may be interested in fixing and sending a pull request? Otherwise I'll take a look at it in the next week or two. |
I was looking at trying to fix it, but I didn't just want to go in and change stuff while breaking everything. If you're okay reviewing any changes I make to make sure they're not going to mess everything up, I'd be more than happy to give it a shot. |
Absolutely. Since we suspect the bug is simply the way the queue gets populated, we should be able to start with a simple unit test illustrating the bug. Have a look at some of these for example: https://github.com/shazow/urllib3/blob/master/test/test_connectionpool.py urllib3 should be very thoroughly tested so hopefully we won't need to worry about breakage too much. :) |
@shazow: Could you run your tests of 358c789? I'm seeing the following failures. Just want to make sure I'm not missing something.
|
Hmm, passes on Tornado 2.1.1, fails on Tornado 2.3. Wonder what changed. |
* Always returning connections to the pool, unless release_conn == False * Adding test cases for all the exceptions in urlopen to verify pool never gets empty * Moved SocketError exception handling to is_connection_dropped to simplify urlopen
Alrighty, 1bbda4e is linked and contains the fixes. If you could review, I would greatly appreciate it. |
Took a quick glance, looks good! I'll take a more thorough look this weekend and merge it in. Thanks for doing this, @thatguystone. You're welcome to add yourself to the CONTRIBUTORS.txt if you wish. :) |
+1 please merge fix in. Thanks! |
Looks like this has been merged? Hard to tell because it wasn't a real Github pull request. :) Please reopen if I'm mistaken. |
Just created #86 for this bug. Not sure why I couldn't just make this a pull request :-\ |
In our production environment, we've noticed the following errors in our logs, pool size set to 500:
After a bit of investigation, it looks like the number of connections in the pool is slow decreasing over time as we encounter other errors, forced timeouts, etc. On urllib3/connectionpool.py:424, if httplib/socket raises an error, the connection will be dropped from the pool because it was acquired on 382 and never put back on line 431 since
conn == None
.This issue can be replicated with the following gist (uses gevent.Timeout, so quasi-related to #69): https://gist.github.com/2932793
It looks like the
if conn
on line 431 was originally added to ensure that a SocketError raised from_get_conn()
didn't addNone
to the pool since a connection would never be gotten, but in the current incarnation, it has the effect of causing the pool size to shrink over time if a connection is acquired and any error is raised from httplib/socket.The text was updated successfully, but these errors were encountered: