yup definitely use loopback address (hostnames are not very reliable on such ephemeral nodes environments)
On Mon, 19 Apr 2021 at 18:15, Tibor Digana <tibordig...@apache.org> wrote: > 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 > >> > >> > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
