[ 
https://issues.apache.org/jira/browse/SUREFIRE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Falko Modler updated SUREFIRE-1800:
-----------------------------------
    Description: 
I was really looking forward to the new TCP process communication (thanks for 
that!) but it seems it has a fundamental issue in non-trivial network setups:

After adding:
{code:xml}
<forkNode 
implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
{code}
my test executions are getting stuck at:
{noformat}
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
{noformat}
{{-X}} reveals:
{noformat}
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[DEBUG] Determined Maven Process ID 15428
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the 
implementation class 
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:  [omitted]
[DEBUG] boot(compact) classpath:  [omitted]
[DEBUG] Forking command line: cmd.exe /X /C 
"C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar 
C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
 C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1 
surefire6381289732609561853tmp surefire_02272472648642066547tmp"
{noformat}
The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only 
network adapters. So that won't work.
>From my naive perspective, I would have expected 127.0.0.1.

I debugged the constructor of {{SurefireForkChannel}} and there 
{{Inet4Address.getLocalHost()}} is returning the wrong IP.
 At this point I am asking myself why {{SurefireForkChannel}} isn't simply 
using {{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
 Alternatively a {{bindAddress}} parameter would come in handy.

  was:
I was really looking forward to the new TCP process communication (thanks for 
that!) but it seems it has a fundamental issue in non-trivial network setups:

After adding:
{code:xml}
<forkNode 
implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
{code}
my test executions are getting stuck at:
{noformat}
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
{noformat}

{{-X}} reveals:
{noformat}
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[DEBUG] Determined Maven Process ID 15428
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the 
implementation class 
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:  [omitted]
[DEBUG] boot(compact) classpath:  [omitted]
[DEBUG] Forking command line: cmd.exe /X /C 
"C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar 
C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
 C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1 
surefire6381289732609561853tmp surefire_02272472648642066547tmp"
{noformat}

The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only 
network adapters. So that won't work.
I would have expected 127.0.0.1 at this point.

I debugged the constructor of {{SurefireForkChannel}} and there 
{{Inet4Address.getLocalHost()}} is returning the wrong IP.
At this point I am asking myself why {{SurefireForkChannel}} isn't simply using 
{{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
Alternatively a {{bindAddress}} parameter would come in handy.


> SurefireForkChannel binds to wrong IP
> -------------------------------------
>
>                 Key: SUREFIRE-1800
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1800
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: process forking
>    Affects Versions: 3.0.0-M5
>         Environment: $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Develop\some-project\middleware\_develop\maven\default
> Java version: 11.0.7, vendor: AdoptOpenJDK, runtime: 
> C:\Develop\some-project\middleware\_develop\java\default
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>            Reporter: Falko Modler
>            Priority: Major
>
> I was really looking forward to the new TCP process communication (thanks for 
> that!) but it seems it has a fundamental issue in non-trivial network setups:
> After adding:
> {code:xml}
> <forkNode 
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
> {code}
> my test executions are getting stuck at:
> {noformat}
> [INFO] -------------------------------------------------------
> [INFO]  T E S T S
> [INFO] -------------------------------------------------------
> {noformat}
> {{-X}} reveals:
> {noformat}
> [INFO] -------------------------------------------------------
> [INFO]  T E S T S
> [INFO] -------------------------------------------------------
> [DEBUG] Determined Maven Process ID 15428
> [DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the 
> implementation class 
> org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
> [DEBUG] boot classpath:  [omitted]
> [DEBUG] boot(compact) classpath:  [omitted]
> [DEBUG] Forking command line: cmd.exe /X /C 
> "C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar 
> C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
>  C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1 
> surefire6381289732609561853tmp surefire_02272472648642066547tmp"
> {noformat}
> The problem here is that 192.168.99.1 is a IP of one of my VirtualBox 
> Host-Only network adapters. So that won't work.
> From my naive perspective, I would have expected 127.0.0.1.
> I debugged the constructor of {{SurefireForkChannel}} and there 
> {{Inet4Address.getLocalHost()}} is returning the wrong IP.
>  At this point I am asking myself why {{SurefireForkChannel}} isn't simply 
> using {{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
>  Alternatively a {{bindAddress}} parameter would come in handy.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to