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
>>
>>

Reply via email to