Gradle build failure with Java 7


(sergey.morenets) #1

Hi

I’m trying to move from Java 6 to Java 7. When I use Java 6 Gradle works properly. However after I’ve upgraded to Java 1.7.0.15 I observe the following behavior:

When I try to build the projects that suppose to open web connection, for example, download some artifacts, the exception is raised:

java.net.SocketException: Permission denied: listen.

I tried to disable firewall, antivirus, etc but it didn’t help. When I use Java 6 Gradle works properly.

Can you please suggest?


(Peter Niederwieser) #2

It’s most likely an issue with your Java 7 installation. Sounds like you have a security policy in place that doesn’t allow listening on a socket.


(sergey.morenets) #3

Hi, Peter

Thank you for the response. It looks like Java 7 uses IPv6 and that can cause issue. There is a JVM setting java.net.preferIPv4Stack that might help.

I tried to add -Djava.net.preferIPv4Stack=true to the Gradle config files but it didn’t help

  1. I added this line to gradle.properties in the project folder org.gradle.jvmargs=-Djava.net.preferIPv4Stack=true

  2. I started Gradle and included it in the parameters gradle -Djava.net.preferIPv4Stack=true --info build

However I see from the logs that Gradle worker still doesn’t use this property. Can you please clarify how to add this JVM property?

Starting process ‘Gradle Worker 1’. Working directory: c:\Project

Command: C:\Program Files\Java\jdk1.7.0_15\bin\java.exe

-Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=windows-1251 -ea -cp

C:\Users\admin.gradle\caches\1.6\workerMain\gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain


(Peter Niederwieser) #4

Many people use Gradle with Java 7, so I’d be surprised if the ‘preferIPv4Stack’ flag would solve your problem.

The Gradle Worker that you refer to is the JVM that runs your tests, not the JVM that runs the build. The JVM arguments for test JVMs can be modified by configuring the ‘test’ task (see ‘Test’ in the Gradle Build Language Reference). But if, as you say, the problem occurs while Gradle is downloading dependences, you won’t have to configure the test JVMs.


(sergey.morenets) #5

Thank you, Peter.

I added this setting but it didn’t help. Would it possible to run gradle in the debug mode and attach output?

Would it help to investigate the issue?


(sergey.morenets) #6

Hi

Here is debug log of the running testing phase. It seems that gradle workers(that run in parallel) are trying to open sockets for their internal use. So that might be the issue

08:54:01.801 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process ‘Gradle Worker 1’ 08:54:02.227 [QUIET] [system.out] 08:54:02.225 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer@53bfbe41, org.gradle.logging.internal.logback.LogbackLoggingConfigurer@5163c85b, org.gradle.logging.internal.JavaUtilLoggingConfigurer@6df6f81b] 08:54:02.503 [QUIET] [system.out] 08:54:02.503 [DEBUG] [org.gradle.messaging.remote.internal.inet.TcpOutgoingConnector] Attempting to connect to [dc226118-87b1-4ba1-8e66-a167f029d2e9 port:50785, addresses:[/127.0.0.1, /0:0:0:0:0:0:0:1]]. 08:54:02.504 [QUIET] [system.out] 08:54:02.503 [DEBUG] [org.gradle.messaging.remote.internal.inet.TcpOutgoingConnector] Trying to connect to address /127.0.0.1. 08:54:02.511 [QUIET] [system.out] 08:54:02.510 [DEBUG] [org.gradle.messaging.remote.internal.inet.TcpOutgoingConnector] Connected to address /127.0.0.1. 08:54:02.625 [QUIET] [system.out] 08:54:02.625 [DEBUG] [org.gradle.process.internal.child.ActionExecutionWorker] Starting Gradle Worker 1. 08:54:02.627 [QUIET] [system.out] 08:54:02.626 [INFO] [org.gradle.api.internal.tasks.testing.worker.TestWorker] Gradle Worker 1 executing tests.


(Luke Daley) #7

The workers have to open sockets so that they can communicate.

The thing to work out is why doing so is an issue on your system.


(sergey.morenets) #8

Hi

I have a project where I configured test task:

test {

jvmArgs ‘-Djava.net.preferIPv4Stack=true’
executable ‘C:/Program Files/Java/jdk1.6.0_43/bin/javaw.exe’
}

When I run test task I suppose Gradle will use Java 6 to run the tests(and also use IPv4 protocol).

gradle -Djava.net.preferIPv4Stack=true test

However I see in my firewall that Gradle opens(or tries to open) 6 TCP connections. Five of them are TCPv4 opened by javaw.exe. And one is java.exe(which is Java 7) and TCPv6.

TCPv6 somehow doesn’t work with Gradle so overall tests failed.

This reply was created from a merged topic originally titled Gradle test task doesn’t use configuration values.


(Luke Daley) #9

Many people are using Java 7 with Gradle and IPv6 with no problem. There’s something particular about your environment. I think you’re hitting Java bug 7179799, which I can’t find a working link for.

I don’t understand why you are getting so many test workers. Do you have ‘maxParallelForks’ set for the test task?


(sergey.morenets) #10

Yes, I found release notes where it mentioned. http://www.oracle.com/technetwork/java/javase/7u6-relnotes-1729681.html

I don’t have maxParallelForks setting in my project. But I added this block into build.gradle to test the setting

test {

maxParallelForks = 1 }

However I still see 3 Gradle workers and 6 TCP connections …


(Luke Daley) #11

I would only expect to see one worker in that case. The other workers may be the Daemon process of compiler daemons.

What language is your project? Java, Groovy, Scala?


(sergey.morenets) #12

Language is Java.

That’s Ok with me if it’s daemon process. The only thing I am missing how to setup TCPv4 parameter for it.


(sergey.morenets) #13

If you’d like I can attach debug output of the gradle build in the debug mode.


(sergey.morenets) #14

Finally resolved.

I had to specify additionally in the batch file. set GRADLE_OPTS=-Djava.net.preferIPv4Stack=true