I'm giving this to Daniel Beck until he figures out who is going to work on this.

When I used localhost with IE, I got a white page. But when I entered the page from another PC with chrome through the IP-Address:8080 I got the pop-up and finish the installation. Even without configured a proxy.

Interesting. Could be as simple as a browser issue. What version of IE is this?

FYI kzantow

Can you click 'x' on the top right and escape into the regular Jenkins page? I feel better if there's an escape hatch for people who hit this problem.

IMHO, Setup wizard should include the proxy configuration as an additional step.

recena It already exists (I can access it when I disable Wi-Fi), but somehow doesn't work for people with actual proxies.

IE 8 you get just a white page (yeah its old, but it's a standard win7 VM for testing ...) Without any pop-up, so you can't do anything. When I skipped as written above the pop-up from another PC the IE works fine.

We have not supported IE 8 since September 2014.
https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix

Unsupported browser.

danielbeck I think we can still improve the user experience here and show some form of an error instead of simply a white screen that doesn't help the user diagnose the issue at all.

Even just a link at the bottom of the page with something like "(Browser Support)" to the wiki page you linked would be better IMHO

I think its not a browser problema. I'm under a proxy and facing the same black page problem in 2.0-alpha-3 version.
I've tried both firefox and chrome.

16-Mar-2016 18:39:19.152 INFO [UpdateCenter.init] hudson.model.UpdateCenter.init This is a new Jenkins instance. The Plugin Install Wizard will be launched.
16-Mar-2016 18:39:25.423 INFO [Download metadata thread] null.null Started Download metadata
16-Mar-2016 18:39:36.308 INFO [SSHD.init] null.null Started SSHD at port 52988
16-Mar-2016 18:39:36.750 INFO [Finalizing set up] org.springframework.context.support.AbstractApplicationContext.prepareRefresh Refreshing org.springframework.web.context.support.StaticWebApplicationContext@65fd755c: display name [Root WebApplicationContext]; startup date [Wed Mar 16 18:39:36 CET 2016]; root of context hierarchy
16-Mar-2016 18:39:36.750 INFO [Finalizing set up] org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@65fd755c]: org.springframework.beans.factory.support.DefaultListableBeanFactory@42ca35ca
16-Mar-2016 18:39:36.791 INFO [Finalizing set up] org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@42ca35ca: defining beans [authenticationManager]; root of factory hierarchy
16-Mar-2016 18:39:37.449 INFO [Finalizing set up] org.springframework.context.support.AbstractApplicationContext.prepareRefresh Refreshing org.springframework.web.context.support.StaticWebApplicationContext@21177d98: display name [Root WebApplicationContext]; startup date [Wed Mar 16 18:39:37 CET 2016]; root of context hierarchy
16-Mar-2016 18:39:37.449 INFO [Finalizing set up] org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@21177d98]: org.springframework.beans.factory.support.DefaultListableBeanFactory@7341ab03
16-Mar-2016 18:39:37.451 INFO [Finalizing set up] org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@7341ab03: defining beans [filter,legacy]; root of factory hierarchy
16-Mar-2016 18:39:40.219 WARNING [UpdateCenter.init] null.null Upgrading Jenkins. Failed to update default UpdateSite. Plugin upgrades may fail.
 java.net.ConnectException: Connection timed out: connect
	at java.net.DualStackPlainSocketImpl.connect0(Native Method)
	at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:589)
	at java.net.Socket.connect(Socket.java:538)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1167)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1103)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:997)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:931)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1511)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
	at hudson.model.DownloadService.loadJSON(DownloadService.java:165)
	at hudson.model.UpdateSite.updateDirectlyNow(UpdateSite.java:174)
	at hudson.model.UpdateCenter.updateDefaultSite(UpdateCenter.java:1900)
	at hudson.model.UpdateCenter.init(UpdateCenter.java:1892)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:106)
	at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:176)
	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
	at jenkins.model.Jenkins$8.runTask(Jenkins.java:975)
	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Can't connect to default UpdateSite.

In the browser, unlimited calls to the following url (http://localhost:8080/jenkins/updateCenter/connectionStatus?siteId=default&_=XXXXXXXXXXXXXXXXX).

Any suggestions?

I solved my issue, sorry for generating any noise.

I had proxy configuration declared in setenv.bat and I was lauching tomcat as a service in windows 10.

set JAVA_OPTS=-Xms256m -Xmx256m -XX:MaxPermSize=128m -Djava.awt.headless=true -Dhttp.proxyHost=XXXXXX -Dhttp.proxyPort=8080 -Dhttps.proxyHost=XXXXXX -Dhttps.proxyPort=8080

Variables declared in that file were no loaded at statup.

Launching tomcat from startup.bat script (not as a service) it takes into account setenv.bat script so proxy properties are properly charged at startup.

I hope this can help anyone.

Apparently not limited to IE8.

jmcubel Not really, if a proxy is required but not configured, a dialog should pop up offering to configure a proxy for Jenkins.

Also getting the white page with Chrome 46 behind a corporate proxy

jmcubel's advice worked for me, although i had to configure the proxy again in jenkins

Daniel says: Issue appears to be real, next step is pointing Keith to it.

Gave it a try behind the company firewall from a fresh alpha-3 install with Docker, and it takes indeed a long time to even get the auth token (after the timeout expiration).

Did a screencast of that https://dl.dropboxusercontent.com/u/6790263/JENKINS-33557-demo.ogv (use VLC, seems like other readers get crazy). A bit long and dull, but at least it shows the issue.

danielbeck I've not been able to reproduce this; running the latest Jenkins a proxy seems to be functioning properly for me. batmat are you able to show/copy the network log from Chrome or Firefox when experiencing this issue?

Yup, kzantow just retried. The browser/client side sends a bunch of requests repeatedly to the Jenkins server (1000+ during the ~2 minutes of my test).

And Jenkins answers:

{"status":"ok","data":{"updatesite":"UNCHECKED","internet":"CHECKING"}}

Then idles, then after ~5 minutes, each request starts being very slow waiting for the server (2.1 minutes), and each time answers:

{"status":"ok","data":{"updatesite":"UNCHECKED","internet":"FAILED"}}

But the page with the three vertical stripes will not go away.

kzantow batmat Could you clarify whether you're running alpha 4, or the latest SNAPSHOT? Maybe there's a difference there?

batmat If the request lingers on the server, could you get a thread dump of the Jenkins Java process?

danielbeck Indeed, running alpha-3 through a Docker container. (I like it because it easily guarantees that I'm starting from a totally clean/empty instance). Btw, I filed JENKINS-33718 about the missing alpha-4 Docker image.

Also, about the thread dump, can do, but really seems like simply an obvious case where Jenkins is trying to access the Internet, when it won't ever be able to do until I set some proxy configuration (+authenticated) in the Jenkins UI. But that Jenkins UI won't show up.

batmat To clarify, you're actually behind a proxy, or you turned off your network connection? Because I repeatedly tested this during various stages of 2.0 with the latter, and never had a problem. So it does not seem as straightforward as "no internet, no Jenkins".

danielbeck behind a corporate authenticated proxy. Network connection is all normal.
In Jenkins 1.x, I have to configure the authentication in /pluginManager/advanced / HTTP Proxy Configuration. Here I won't be able to access that page.

And I just double-checked entering the running container using docker exec: I was not able to access the Internet (testing w/ curl) until I set the http_proxy var, then it worked. So the network stack of the container actually works (which indeed I happen to have had some issue with in the past).

Side note: I can workaround all that by adding /configure manually on the address bar, but as it still seemed to me we're talking first-hand experience here, I guess it's not satisfactory.

danielbeck thread dump during the issue: https://gist.github.com/batmat/eae870f0f2c7f3c0ee6d

And indeed:

"Handling GET /updateCenter/connectionStatus from 172.17.0.1 : RequestHandlerThread[#7]" Id=77 Group=main RUNNABLE (in native)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	-  locked java.net.SocksSocketImpl@5b130b5d
      ...

Probably something about the network that does not cause an immediate abort. Needs a more aggressive timeout, say, 10-20 seconds.

Yup, probably the firewall DROP ing packets instead of REJECT ing them. (compared to your case having disabled network, where probably packets will likely immediately return in error)
And yes too to lowering the timeout, currently Jenkins appears frozen from a newcomer standpoint in that situation (I gave it more than 10 minutes, and it stayed on that page).

batmat thanks much, I think you've highlighted where to start with this issue, I should be able to get it addressed based on your feedback.

kzantow you're welcome.
Possibly, I guess that that could be around https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/UpdateCenter.java#L905 and intermediately setting connectTimeout and/or readTimeout, but still a bit wild guess since I didn't thoroughly analyze the whole call stack.

batmat danielbeck also, to clarify, I configured a squid proxy both with and without internet connectivity and the UI returned promptly as expected. The behavior you are seeing is not very straightforward to reproduce, it's limited to a proxy allowing connections to timeout rather than immediately returning failure codes, perhaps a misconfigured proxy. This results in stock TCP timeouts of presumably 3 minutes for each of 2 connections = 6 minutes of waiting, which obviously is very excessive. Anyway, I've made a change and included here, would you be able to verify with the build that Jenkins returns in a timely manner (currently it's 20 seconds, and the 2 checks now happen in parallel). https://github.com/jenkinsci/jenkins/pull/2156

batmat https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/4473/ will be a PR build with Keith's changes.

batmat would you be able to verify this PR corrects the issue for you?

https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/4473/artifact/war/target/jenkins.war

Thanks!

New PR build: https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/4495/

Indeed better, congrats.

Now it stayed ~2 minutes on the first screen "Please wait while Jenkins is getting ready to work" until the first timeout:

Mar 23, 2016 9:27:03 AM hudson.model.UpdateCenter updateDefaultSite
WARNING: Upgrading Jenkins. Failed to update default UpdateSite. Plugin upgrades may fail.                                                                  
java.net.ConnectException: Connection timed out             

Then I could access the "Unlock Jenkins" page, where I pasted the generated hash.
And then, it took again ~1/2 minutes to timeout and present me with "Offline" page, letting me access the proxy config, and then it worked smoothly as usual.

Nitpicking, and probably for another issue, now I think the default initial message is actually not perfect (see attached screenshot).
The message "Finish the upgrade process...", even if I started with a clean instance using docker run -v $PWD/jenkins.war:/jenkins.war:ro -p 10000:8080 -it java:7 java -jar /jenkins.war might be misleading, don't you think?

Maybe it's just because I'm no native speaker, but "upgrading" makes me think about "upgrading" an existing instance. Thinking about it, maybe we should just go to the point the user is interested in.

Meaning:

instead of

Welcome to Jenkins v2! Click here to install the rest of v2 functionalities and finish the upgrade process

Something shorter like:

Welcome to Jenkins v2! Click here to install additional features you need

WDYT?

Welcome to Jenkins v2! Click here to install additional features you need

batmat 2 Minutes seems to still be pretty long. Could you take a few more stack traces during that time (also the second 30 seconds), maybe there's still a code path to a connection without custom timeout?

Or WDYT of shorter timeouts such as 10s? Also, what happens in Jenkins 1.x when you "test" the proxy configuration without having defined a proxy? Does it also take long (according to https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/ProxyConfiguration.java#L332 it should be 30 seconds)?

batmat can we move the discussion of the terminology for 'upgrading' jenkins 1 to 2 to this ticket: JENKINS-33663 ? there will be changes to the procedure, and I think text changes are appropriate to be included there. If you are seeing this banner with a NEW installation, there's a bug, it's not supposed to happen, which is why the term 'upgrading' is included.

Could you verify the latest build addresses both of the excessive wait time issues for you I've lowered the default timeout to 20 seconds? You should expect to see: 20 second wait time at first, and a 20 second wait time when first loading the wizard. We could lower it more, I don't know what a reasonable minimum is, though... even 10 seconds seems long to me... either Jekins can connect to an external site in 10 seconds or there are probably some network issues, that's probably a decision for a different ticket.

https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/4517/artifact/war/target/jenkins.war

New screencast made with 1417cd37b8e83030ee9d4b7ff0e4a349 (https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/4523/artifact/war/target/jenkins.war)

https://dl.dropboxusercontent.com/u/6790263/JENKINS-33557-1417cd37b8e83030ee9d4b7ff0e4a349.ogv

kzantow and bug confirmed, then. See screencast. I filed JENKINS-33767 about that.

IMO, the first timeout/part can be considered resolved. The second part still takes roughly 45 seconds.

Way to go anyway, it's heading in the right direction.

And re-reading myself, I didn't answer: I also think that 10, or say 15, seconds should always be sufficient.

Code changed in jenkins
User: kzantow
Path:
core/src/main/java/hudson/model/UpdateCenter.java
http://jenkins-ci.org/commit/jenkins/52c4ed6da03ea02cff54f7a31dad62c55d6e8c94
Log:
JENKINS-33557 - tcp timeouts cause installer to hang for 6 minutes

Code changed in jenkins
User: kzantow
Path:
core/src/main/java/hudson/Functions.java
core/src/main/java/hudson/model/Descriptor.java
core/src/main/java/hudson/model/ManageJenkinsAction.java
core/src/main/java/hudson/tools/ToolDescriptor.java
core/src/main/java/jenkins/install/SetupWizard.java
core/src/main/java/jenkins/management/ConfigureLink.java
core/src/main/java/jenkins/model/GlobalConfiguration.java
core/src/main/java/jenkins/model/GlobalConfigurationCategory.java
core/src/main/java/jenkins/model/Jenkins.java
core/src/main/java/jenkins/mvn/GlobalMavenConfig.java
core/src/main/java/jenkins/tools/GlobalToolConfiguration.java
core/src/main/java/jenkins/tools/ToolConfigurationCategory.java
core/src/main/resources/hudson/logging/LogRecorder/sidepanel.jelly
core/src/main/resources/hudson/logging/LogRecorderManager/index.jelly
core/src/main/resources/hudson/logging/LogRecorderManager/sidepanel.jelly
core/src/main/resources/hudson/model/ComputerSet/index.jelly
core/src/main/resources/hudson/model/ComputerSet/sidepanel.jelly
core/src/main/resources/hudson/model/Job/configure.jelly
core/src/main/resources/hudson/model/Label/sidepanel.jelly
core/src/main/resources/hudson/model/UpdateCenter/sidepanel.jelly
core/src/main/resources/hudson/model/User/sidepanel.jelly
core/src/main/resources/hudson/security/HudsonPrivateSecurityRealm/index.jelly
core/src/main/resources/hudson/security/HudsonPrivateSecurityRealm/sidepanel.jelly
core/src/main/resources/jenkins/install/SetupWizard/authenticate-security-token.jelly
core/src/main/resources/jenkins/install/pluginSetupWizard.properties
core/src/main/resources/jenkins/management/Messages.properties
core/src/main/resources/jenkins/tools/GlobalToolConfiguration/index.groovy
core/src/main/resources/lib/hudson/project/configurable.jelly
test/src/test/java/hudson/model/HudsonTest.java
test/src/test/java/hudson/tasks/MavenTest.java
test/src/test/java/hudson/tools/JDKInstallerTest.java
war/src/main/js/api/plugins.js
war/src/main/js/pluginSetupWizardGui.js
war/src/main/js/templates/progressPanel.hbs
war/src/main/less/pluginSetupWizard.less
war/src/main/webapp/css/style.css
http://jenkins-ci.org/commit/jenkins/2fbf73fc76e32698c7d9f8b17cf7325d96fa5513
Log:
Merge remote-tracking branch 'primary/2.0' into JENKINS-33557-tcp-timeouts-during-install

Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/ProxyConfiguration.java
core/src/main/java/hudson/model/UpdateCenter.java
test/src/test/java/hudson/model/UpdateCenterConnectionStatusTest.java
http://jenkins-ci.org/commit/jenkins/ee5c1a3a133e203f0296c3238798b4a7c5b92b8e
Log:
Merge pull request #2156 from kzantow/JENKINS-33557-tcp-timeouts-during-install

JENKINS-33557 - connectivity checks may cause setup wizard to hang for a long time

Compare: https://github.com/jenkinsci/jenkins/compare/6a74607b4ef0...ee5c1a3a133e

Timeouts have been reduced and made configurable, I think we can close this? batmat kzantow?

+1 from me danielbeck, though there's probably still some room for improvement, it's now perfectly usable. And as we're talking about a one-shot screen I guess it's enough for now.
Thanks