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