Closed olleolleolle closed 6 years ago
In order to see if it was a regression, I moved down to jruby-9.1.14.0, and found the same failure on my macOS machine:
$ rspec --bisect
Bisect started using options: ""
Running suite to find failures... (11.5 seconds)
Starting bisect with 1 failing example and 101 non-failing examples.
Checking that failure(s) are order-dependent... failure(s) do not require any non-failures to run first
Bisect complete! Reduced necessary non-failing examples from 101 to 0 in 8.93 seconds.
The minimal reproduction command is:
rspec './spec/nio/selectables/udp_socket_spec.rb[1:1:3]'
Huh, strange. It's persisting across a retry on Travis too. May have to add it to the tests we skip on JRuby
@headius @enebo don't suppose you have any idea why we'd start seeing IOError
with UDP sockets, do you?
Does JRuby support UDP sockets?
https://github.com/jruby/jruby/pull/4684 was one issue I had.
Does JRuby support UDP sockets?
Yes, and these tests were previously passing on JRuby
@tarcieri There have been some changes over the summer to "improve" socket errors. Perhaps one of these was in error. We should investigate.
This may have never passed. It appears that the failing spec was just added earlier this year: f8e468cc34ba90c62a978892143592b44fb0094f
This is likely an easy fix; we're just not handling a connection error by raising the appropriate Errno exception.
I have a fix. The JDK's UDP subsystem was raising java.net.PortUnreachableException
, which appears to be the UDP equivalent of a connection refused. With JRuby fixed to raise ECONNREFUSED, we get the apparently-intermittent skip behavior in the spec.
Should be good now.
@headius sweet, thank you!
This PR updates the CI matrix to use latest JRuby.
http://jruby.org/2017/12/07/jruby-9-1-15-0.html