lanto03 / couchdb-python

Automatically exported from code.google.com/p/couchdb-python
Other
0 stars 0 forks source link

Software caused connection abort #125

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

Any request to couchdb after some period of time

What is the expected output? What do you see instead?
expected: data
instead: socket.error file 'http.py' line 'return conn.getresponse()'

What version of the product are you using? On what operating system?

Windows XP SP3, python 2.5, couchdb version 0.11.0

Please provide any additional information below.

Adding errno.ECONNABORTED in the following line worked for me.
if retries > 0 and ecode in [errno.ECONNRESET, errno.ECONNABORTED, errno.EPIPE]:

Original issue reported on code.google.com by sen...@gmail.com on 11 May 2010 at 8:43

GoogleCodeExporter commented 8 years ago
Connection aborting is normal behavior for socket connection. But I couldn't 
see any
reasons why couchdb-python doesn't take any attempt to retry request for this 
situation.

+1 for this issue.

Original comment by kxepal on 13 May 2010 at 1:55

GoogleCodeExporter commented 8 years ago
This is just one of many cases that I added in my retry fork of this project.  
I also made retrying more robust by 
adding an optional retry schedule.  In practice I find the schedule and the 
increased robustness very useful, but I 
admit that the interface looks non-standard.  Comments on how to bring a robust 
retry heuristic in line with 
common practice would be appreciated.

http://code.google.com/r/jamesbergstra-couchdb-python-with-retry/source/browse

Original comment by james.be...@gmail.com on 13 May 2010 at 2:13

GoogleCodeExporter commented 8 years ago
ECONNABORTED is a default retryable error as of revision 74073207e8. That, 
coupled 
with James's retry_delays (revision adcaeede26) should allow you to configure 
the HTTP 
layer to cope with these sorts of glitches.

As for retry heuristics ... a list of timeouts is a good first step. We can now 
easily 
allow retry_delays to be a callable that generates the retry delays to cope 
with 
anything more custom.

Original comment by matt.goo...@gmail.com on 20 May 2010 at 2:05