I had this problem with GH CI: java.net.BindException: Cannot assign requested address at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:461) at sun.nio.ch.Net.bind(Net.java:453) at sun.nio.ch.AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)
and solved it see https://github.com/apache/maven-surefire/commit/a88881d3866eb0dd81eeeee8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84 and now the CI is green. I guess we have the same problem in our ITs. T On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana <tibordig...@apache.org> wrote: > Port 0 does not exist, only in your code. > 0 means that a new unused local port is allocated. > Again you have to use local loopback 127.0.0.1 as me. I had the same > problem and I solved it. > T > > On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders <mthmuld...@apache.org> > wrote: > >> All of those tests seem to follow the process of starting a server at >> port 0 indeed. Some tests even start two servers in one test: >> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And >> in all three scenarios they use >> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their >> hostname. I'm not sure if that's the best way to do it? >> >> Interestingly, I now see that those tests do not *always* fail on Linux. >> During the last GitHub Action run (640, [1]), two out of four Linux jobs >> actually succeeded. The failing ones logged stuff like this: >> >> >> Connect to fv-az154-166.internal.cloudapp.net:34307 >> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed >> out (Connection timed out) >> >> Connect to fv-az292-806.internal.cloudapp.net:33785 >> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed >> out (Connection timed out) >> >> >> Interestingly, they seem to not be able to connect, but the name lookup >> doesn't seem the issue, right? >> >> >> Thanks, >> >> >> Maarten >> >> >> [1] https://github.com/apache/maven/actions/runs/761300517 >> >> >> On 19/04/2021 00:31, Tibor Digaňa wrote: >> > yes, there was one more issue with host. >> > I also had to turn "localhost" to 127.0.0.1 in the socket. >> > T >> > >> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy <ol...@apache.org> wrote: >> > >> >> Hi, >> >> Do not change ports or use hard coded ports. >> >> The current ITs are using port 0 which means Jetty will allocate a >> >> random available port. >> >> There must be some problems with host lookup. In some environments >> (such as >> >> kubernetes) using localhost or 127.0.0.1 can be problematic. >> >> What is the error? >> >> >> >> What is the status of using java8 for IT tests? (current ITs are using >> a >> >> very very old version of Jetty 9.0.4...) >> >> >> >> >> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana <tibordig...@apache.org> >> wrote: >> >> >> >>> I had exactly the same problem and I added one more step to the CI >> which >> >>> checked all open ports. >> >>> For instance they changed something in Github and 8081 or 8082 was >> >>> allocated. >> >>> There was a conflict with the ports and I had to shift mine, that;s >> it. >> >>> >> >>> T >> >>> >> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders < >> mthmuld...@apache.org> >> >>> wrote: >> >>> >> >>>> Hi all, >> >>>> >> >>>> It seems the following IT's predictably fail on Linux (not on Windows >> >> or >> >>>> MacOS) in GitHub Actions, but not at all in Jenkins: >> >>>> >> >>>> * MavenIT0146InstallerSnapshotNaming >> >>>> * MavenITmng2387InactiveProxyTest >> >>>> * MavenITmng4991NonProxyHostsTest >> >>>> >> >>>> This is also the case in master, by the way. What they have in common >> >> is >> >>>> that they all spin up an HTTP server during the test, but apparently >> >>>> that server cannot be reached under all circumstances. >> >>>> >> >>>> Does anyone have an idea what might be causing this and how we could >> >>>> address this? >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Maarten >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>>> For additional commands, e-mail: dev-h...@maven.apache.org >> >>>> >> >>>> >> >>> >> >> >> >> >> >> -- >> >> Olivier Lamy >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
