Skip to content

Replace Timeout.timeout with TCPSocket.open(open_timeout:) when available #224

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Nov 10, 2025
Merged

Replace Timeout.timeout with TCPSocket.open(open_timeout:) when available #224

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
728eb8f
Replace Timeout.timeout with TCPSocket.open(open_timeout:) when avail…
osyoyu Jul 16, 2025
09bf573
Ruby 2 compat
osyoyu Jul 22, 2025
06d982f
Remember if TCPSocket impl supports open_timeout
osyoyu Nov 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 15 additions & 7 deletions lib/net/http.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1654,14 +1654,22 @@ def connect
end

debug "opening connection to #{conn_addr}:#{conn_port}..."
s = Timeout.timeout(@open_timeout, Net::OpenTimeout) {
begin
TCPSocket.open(conn_addr, conn_port, @local_host, @local_port)
rescue => e
raise e, "Failed to open TCP connection to " +
"#{conn_addr}:#{conn_port} (#{e.message})"
begin
s = begin
# Use built-in timeout in TCPSocket.open if available
TCPSocket.open(conn_addr, conn_port, @local_host, @local_port, open_timeout: @open_timeout)
rescue ArgumentError => e
Copy link
Contributor Author

@osyoyu osyoyu Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't come up with a better way to detect the absence of open_timeout: option. Is this a acceptable solution?

TCPSocket.open is basically (**args) from the perspective of Ruby, so Method#parameters wasn't an option:

irb(main):001> require 'socket'
=> true
irb(main):002> TCPSocket.method(:open).parameters
=> [[:rest]]

Copy link

@deivid-rodriguez deivid-rodriguez Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine, given this is only to keep things working for very old rubies, right, and the error message is not going to change for those rubies anyways.

Copy link
Contributor Author

@osyoyu osyoyu Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it's not only very old Rubies, but even 3.4 raises on a TCPSocket.open call with open_timeout. It is true that the situation is different in Ruby 2.x, where keyword arguments were not a argument of its own kind (workaround in 09bf573).

Copy link

@deivid-rodriguez deivid-rodriguez Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I thought your question was specifically for the Ruby 2.x workaround, since you need to parse a very generic error message, but I see how the detection for Ruby 3.4 is also brittle since it also involves parsing the error message, even if more specific. Unfortunately, I don't know of a better way, but I'd say this way is acceptable.

Copy link
Contributor

@mohamedhafez mohamedhafez Aug 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that every single new HTTP request is going to go through this raise/rescue flow on ruby < 3.5, and that exceptions are kind of expensive, personally I think a better option is just to have test for RUBY_VERSION.to_f < 3.5 directly to see if we use the old Timeout.timeout. I get that testing version numbers directly is a bit distasteful, but when there's actual performance issues and brittleness issues on the line... I'd say its merited

Copy link
Contributor

@mohamedhafez mohamedhafez Nov 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah Christ. Ractors. Yeah nevermind my suggestion above won't work any more, since it would make it so instances of Net::HTTP wouldn't work inside anything but the main Ractor.

Copy link
Contributor Author

@osyoyu osyoyu Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that’s exactly right. Using class variables would unfortunately kill Ractors.

Copy link
Contributor

@mohamedhafez mohamedhafez Nov 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case I'd still argue that simply testing RUBY_VERSION.to_f >= 3.5 is the more straightforward and efficient way to do it - to address @eregon's arguments: Regarding alternative Rubies, I'd say its their responsibility to implement Ruby 3.5 functionality before advertising compatibility with it in RUBY_VERSION (unless there's some reason why open_timeout specifically would be difficult to implemented in Java?). And in the unlikely case that open_timeout is removed in a future Ruby version, well then an update to this library would be necessary, which is to be expected when behavior is deprecated/removed, and isn't something we usually guard against no? Things would get pretty messy if we did that all over the place.

Just my two cents, and yeah an exception raised on first use of every Net::HTTP instance probably isn't a performance hit we need to be debating a ton. I'll just be happy either way if this hopefully gets merged, and i appreciate the work!! 🙏

Copy link
Member

@eregon eregon Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding alternative Rubies, I'd say its their responsibility to implement Ruby 3.5 functionality before advertising compatibility with it in RUBY_VERSION (unless there's some reason why open_timeout specifically would be difficult to implemented in Java?).

I'm specifically worried about that because open_timeout is resolv_timeout + connect_timeout.
resolv_timeout is extremely complex to handle, CRuby has had many iterations of it (some of them buggy, leaking, segfaulting and other issues) and it will probably be a lot of work to implement it for other Ruby implementations, so I think it's not unlikely e.g. TruffleRuby/JRuby won't support resolv_timeout properly (because the libc doesn't give a way to do interruptible getaddrinfo()) and yet implements other Ruby 4 features.

In such a case maybe open_timeout should be handled as just connect_timeout, but I'm not sure what is the best behavior in such a case. I'd need to check how resolv_timeout is handled on TruffleRuby/JRuby currently.

Copy link
Contributor

@mohamedhafez mohamedhafez Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh i see. Yeah if there's a reason this specifically would be hard to implement in alternative rubies then I wholeheartedly agree with the approach that was merged in, since I'm using alternative Rubies myself;) Thanks for the explanation!

raise if !e.message.include?('unknown keyword: :open_timeout')
# Fallback to Timeout.timeout if TCPSocket.open does not support open_timeout
Timeout.timeout(@open_timeout, Net::OpenTimeout) {
TCPSocket.open(conn_addr, conn_port, @local_host, @local_port)
}
end
}
rescue => e
e = Net::OpenTimeout.new(e) if e.is_a?(Errno::ETIMEDOUT) # for compatibility with previous versions
raise e, "Failed to open TCP connection to " +
"#{conn_addr}:#{conn_port} (#{e.message})"
end
s.setsockopt(Socket::IPPROTO_TCP, Socket::TCP_NODELAY, 1)
debug "opened"
if use_ssl?
Expand Down
Loading