[GRADLE-1543] Tooling API fails to connect to Gradle Daemon in execution environment that has network proxy Created: 13/May/11 Updated: 10/Feb/17 Resolved: 10/Feb/17
|Kris De Volder
My windows box is behind a proxy firewall. I was able to install STS and the Gradle extensions by setting up the proxies by doing the following:
to my STS.ini file right after -vmargs
2) In Eclipse preferences "General >> Network Connections" switch to "manual" and configure the same proxy settings here as well.
After doing that I tried importing the simple "Java quickstart" sample project.
Proxy settings seem to get to Gradle ok... at least the API was able to download milestone 3 zip.
However, it seems to have trouble creating a connection to the Gradle Daemon running on localhost.
I get the following exception:
|Comment by Adam Murdoch [ 15/May/11 ]
Some things to check:
|Comment by Kris De Volder [ 16/May/11 ]
How do I check if the Daemon is running?
I'll give the commandline stuff a try, report back later on.
|Comment by Kris De Volder [ 16/May/11 ]
I've installed the Gradle commandline tools on the windows box (latest snapshot drop from artifactory):
when I do "gradle --daemon" I get this:
Also ran it with the suggested debug options:
|Comment by Szczepan Faber [ 31/May/11 ]
I'm having troubles reproducing the problem.
1. I tried various firewall/proxy configurations on my Windows 7 and mac with milestone-3 and the latest snapshot
Can you share some more details about your environment that can help me reproduce it?
|Comment by Kris De Volder [ 31/May/11 ]
It is a view on a Windows XP VM running behind a proxy firewall.
It could be something in the setup of that machine. But to be honest I'm not sure what info to provide.
It could very well be that the problem isn't Gradle but somehow the machine's proxy configuration isn't quite setup correctly.
If you can't reproduce it, I wouldn't worry too much about it. Just close the bug as 'cannot reproduce'.
|Comment by Szczepan Faber [ 18/Jun/11 ]
I cannot seem to reproduce this issue.
|Comment by Kris De Volder [ 22/Nov/11 ]
One of our user just reported experiencing this kind of problem in STS using milestone 6 snapshot of Gradle.
Maybe this issue should be reopened. I've asked the user to try to provide more details here.
|Comment by Szczepan Faber [ 22/Nov/11 ]
Please provide more info if possible. Thanks!
|Comment by Kris De Volder [ 23/Nov/11 ]
All that I can provide, which may or may not be relevant...
It seems that both cases where there was a problem involved a Windows 32 bit environment.
|Comment by Szczepan Faber [ 24/Nov/11 ]
|Comment by Osama Rashwan [ 10/Feb/12 ]
is equal java home true , is equal DaemonOpts false
|Comment by Adam Murdoch [ 10/Feb/12 ]
@Osama, I suspect you're running into a different problem with the same symptom: http://issues.gradle.org/browse/GRADLE-2089
|Comment by Osama Rashwan [ 11/Feb/12 ]
@Adam Thanks for your replay , yes the issue was because of IBM JDK. and it is fixed after switching to Oracle JDK
|Comment by Michael Brand [ 28/Feb/12 ]
We're seeing a similar problem. We just added a new developer (we already have half a dozen or so), and he is unable to import to SpringSource's STS because of this issue. He's running Windows 7 64 bit and the latest Eclipse Indigo 64 bit. No one else has seen this issue.
We've cached the gradle-1.0-milestone-7-bin.zip file to a local server so that we don't have to deal with firewall issues. We've tried using native, manual, and direct network settings. We've restarted everything.
We are having no problem at the command line, but this consistently fails when trying to import from the SpringSource STS plugin to Eclipse.
Here's a stack trace of the error:
Still get the gradel error when I do it from home. It is the same timeout error: Timeout waiting to connect to Gradle daemon
|Comment by James Anderson [ 08/Mar/12 ]
I am also unable to connect to the Gradle daemon, either from the command line or from STS 2.8/2.9. I'm on WinXP 32bit, with Sun/Oracle JDK 1.6.0_31.
C:\>gradle --daemon --stacktrace
FAILURE: Build failed with an exception.
|Comment by Adam Murdoch [ 08/Mar/12 ]
@James, which version of Gradle are you using (you can run gradle -v to get the details)? Also, could you try with the recent 1.0-milestone-9 snapshot (see http://gradle.org/release-candidate)? There have been a bunch of fixes in this area.
|Comment by Szczepan Faber [ 11/Mar/12 ]
Also, can you run with --debug ?
|Comment by Benjamin Muschko [ 15/Nov/16 ]
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.