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

Reply via email to