Call getaddrinfo from Ruby
#139
Conversation
casperisfine
force-pushed
the
resolve-in-ruby
branch
2 times, most recently
from
34e9763
to
e571c5a
Compare
| assert_equal expected_connection_options, client.connection_options | ||
| actual_options = client.connection_options.dup | ||
| actual_options.delete(:ip_address) | ||
| assert_equal expected_connection_options, actual_options |
There was a problem hiding this comment.
Can we assert ip_address on the expected connection options instead?
| raise Trilogy::BaseConnectionError, "Couldn't resolve host: #{options[:host].inspect}" | ||
| end | ||
|
|
||
| addrs.sort_by!(&:first) # Priority to IPv4 |
There was a problem hiding this comment.
For my own understanding: does prioritizing IPv4 here match what happens when we were calling getaddrinfo directly in trilogy_sock_resolve? Were we resolving to a single address previously, or potentially to multiple? 🤔
There was a problem hiding this comment.
Yeah, that's a good question to which I don't have a proper answer. This PR is more proof of concept territory because I'm not very good at networking, so there might be a much simpler / better way to do this.
The crux is really that I see processes stuck connecting to MySQL, and I highly suspect this is the cause.
casperisfine
force-pushed
the
resolve-in-ruby
branch
from
e571c5a
to
9f6c9f5
Compare
|
I think it's a good idea to use Ruby as much as we can, but I'm also a bit unsure about the IP sorting |
Yeah me too, I think I need to dig a bit more on how this works |
casperisfine
force-pushed
the
resolve-in-ruby
branch
from
9f6c9f5
to
ce43075
Compare
`getaddrinfo` is notorious for not having a timeout, which can make it hang for a very long time. Since Trilogy releases the GVL before calling it, that can cause the whole VM to be unresponsive and no longer respond to ctrl+c etc. In 3.3.0, Ruby is now doing name resolution from a background thread, making `Socket.getaddrinfo` interruptible. So by doing the name resolution on the Ruby side, we should avoid such scenarios.
casperisfine
force-pushed
the
resolve-in-ruby
branch
from
ce43075
to
3c498dd
Compare
Ref: https://bugs.ruby-lang.org/issues/19965
getaddrinfois notorious for not having a timeout, which can make it hang for a very long time. Since Trilogy releases the GVL before calling it, that can cause the whole VM to be unresponsive and no longer respond to ctrl+c etc.In 3.3.0, Ruby is now doing name resolution from a background thread, making
Socket.getaddrinfointerruptible. So by doing the name resolution on the Ruby side, we should avoid such scenarios.@jhawthorn @matthewd @composerinteralia @adrianna-chang-shopify what do you think?