Net::HTTP::Persistent::Error: too many connection resets #37
Comments
|
Hey guys, we found the error. It is depend on version of Ruby. So, please close the issue. Sorry to disturb you. |
|
@featalion which version of Ruby did you update to for fixing this issue? I am seeing a similar failure due to
|
|
@mikerudolph , the oldest version I tested is 1.9.3-p327. But possible earlier, like p192, works too. |
|
@featalion I just tested my code which exhibits this problem on ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux] on an Amazon EC2 instance, and I still get the problem. Do you know what specific change in Ruby you thought resolved this issue? |
|
As I remember, changes in Ruby SSL (non-block reading or so, C code). But I'm not pretty sure it works for any use cases. I tested linux/darwin x64 MRI Rubies and in my cases issues disappear at p327. Also tested p392 and it was OK. |
|
Evident for me on linux-x86_64 1.9.3-p327, typing this error (unable to copy). On net-http-persistent 2.7, and 2.8. It worked for some time in a multithreaded test case, then the error appeared after a minute. Second run happened after quite quicker. |
|
I'm not sure it is thread-safe. For example, program opens one socket and N threads reading/writing at the same time. |
|
net-http-persistent opens a new HTTP socket per thread. Is there a good way for me to reproduce this? I think I will need both the ruby version and the OpenSSL version along with a test script to reproduce it. |
|
I was bitten by the same issue as @mikerudolph above: This is an issue separate from EOFError and SSLError mentioned above, and is easily reproducible. It will occur if the connection was configured with a read timeout and the server didn't reply in a timely fashion. Net::HTTP is going to raise a Timeout::Error and net-http-persistent handles this, among other errors, by resetting the connection, retrying, and ultimately aborting with the misleading message quoted above. I fixed this for myself by monkeypatching net-http-persistent from master to not handle Timeout::Error. In the case of a server taking too long to generate a response, I don't think resetting the connection does us any good since it wasn't a connection problem to begin with. It would be much better to leave the original Timeout::Error unhandled and let the user retry the request if they will. |
|
I also encountered this today: ruby 2.0.0p451 (2014-02-24 revision 45167) [x86_64-darwin12.5.0] |
|
@ifduyue Yours isn't the same issue, as it seems you're getting valid "too many connection resets" errors due to read timeouts. It's probably that you're not giving enough time for the remote server to respond. Try increasing the timeout setting. |
|
@mislav thx, I'll try. |
|
I'm getting this issue with 2.0.0.-p353, and have been trying to debug it for quite a while. I increased my timeout to 600 seconds. That should be way more than enough for the request I'm taking (when doing this in the browser it takes < 10 seconds -- long, but not ten minutes) I don't think I have done 10582 requests; I believe I've only done about 8688 at this point in the program (unless the difference is made by resetting the connection before this via idle timeouts). I'm using the same connection object because it's wrapped in a Mechanize object, but each request should be almost instantaneous (the only processing I do to the result is checking the status) -- so I'm not hitting an idle timeout, right? What does connection resets even mean? Is that when a Net::HTTP::Persistent connection makes a new underlying connection? Why is EOFError appearing here? It seems like this should be throwing a timeout error, since 600 seconds is my read_timeout |
|
I have this issue too coming quite frequently.. Error is: are you guys still having this issue? i cant totally understand what the actual problem is here... |
|
I think it might be due to the 'note' here about it not working for ruby 1.9+ here - https://github.com/drbrain/net-http-persistent/blob/master/lib/net/http/persistent.rb#L241 |
|
Is that comment about trouble with 1.9+ still accurate? It was added to that file in June of 2012. |
|
The concern with the comment is that newer versions of Net::HTTP reconnect automatically. I should rewrite this using TCPSocket only |
|
@drbrain encountering the same error when using Gem-in-a-box |
|
I see this issue very reliably when using neo4j-core 6.1.5, neo4j 7.2.3 and resque-pool 0.6.0, with a worker pool of 4. In my Rails 4.2 project, I have a require 'resque/tasks'
require 'resque/pool/tasks'
task "resque:setup" => [:environment]
task "resque:pool:setup" do
# close any sockets or files in pool manager
Neo4j::Session.current.close
cfg = Rails.application.config.neo4j
# and re-open them in the resque worker parent
Resque::Pool.after_prefork do |job|
$redis.client.reconnect
Neo4j::Session.open(cfg.session_type, cfg.session_path, cfg.session_options.merge( { name: "neo4j_#{Process.pid}",
default: true }))
puts "#{__FILE__}:#{__LINE__}"
p Neo4j::Session.current
# Category is a neo4j Node class
p Category.all.result.count
# Cleanup just in case
at_exit do
Neo4j::Session.current.close
end
end
endWhen I switch the |
|
For completeness, errors I see look like this (a bunch removed - almost all are the "too many bad responses" errors): |
|
Just a ping to see if any progress was being made on this issue? I am seeing the following with a GET request using Mechanize via Tor while trying to get a new identity by restarting Tor service. A flaky |
|
@MatzFan this is always due to network issues so you'll need to perform workarounds outside this library |
|
Understood - thanks @drbrain |
|
No one has yet commented on the fact that the "last used seconds ago" value is sometimes ludicrously high. While writing this, it suddenly twigged that these values point to the UNIX epoch, |
|
possibly fixed by removing retry logic, please comment on #100 if you are interested |
This was reported a while back, but it was closed so making a new one: #19
We get this error a LOT and from searching around the web, it seems other people get it too and they all seem to trace back to net-http-persistent (http://goo.gl/c1Qes). We recently had a user who was getting this pretty consistently, and easily, from a heroku app so we had him try changing the backing gem to rest-client and typhoeus and the problem disappeared using either of those. All our gems are using the 'rest' gem (https://github.com/iron-io/rest) so we just had the user change the backing gem like so:
Here are some examples of what we're seeing on a regular basis, all of these from today:
And so on. All on the same line it appears:
It would be great if we could find a fix because I really like your library, it performs almost as good as typhoeus with no binary dependency which is great.
The text was updated successfully, but these errors were encountered: