Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18366

Jetty should be used rather than Winstone for embedded deployments

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      Hudson recently switched to using Jetty as an embedded servlet engine. It has a very small size, and very very good performance.
      Put bluntly, the current use of Winstone SUCKS, and due to its threaded design will cause performance to slow to a crawl at 240+ requests a minute even on high end hardware with aggressive varnish caching. At the same time using an external Java EE container isn't that easy, so by following hudson and switching to Jetty we get the best of both worlds.

      Thanks
      md_5

          [JENKINS-18366] Jetty should be used rather than Winstone for embedded deployments

          Winstone has ceased the development upstream, so we are the one maintaining it. That obviously doesn't make sense.

          Another benefit is that this would also allow us to start delivering features that depend on WebSockets, etc.

          This work involves writing a new driver code that accepts options that Winstone accepts but instead drive Jetty. For this purpose, I have refactored Winstone to explicitly list up all the options in use.

          The general option compatibility is important so as not to disrupt existing deployments, even if we might consciously decide to skip some uncommon options if those are deemed too hard to match.

          Kohsuke Kawaguchi added a comment - Winstone has ceased the development upstream, so we are the one maintaining it. That obviously doesn't make sense. Another benefit is that this would also allow us to start delivering features that depend on WebSockets, etc. This work involves writing a new driver code that accepts options that Winstone accepts but instead drive Jetty. For this purpose, I have refactored Winstone to explicitly list up all the options in use . The general option compatibility is important so as not to disrupt existing deployments, even if we might consciously decide to skip some uncommon options if those are deemed too hard to match.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          pom.xml
          war/pom.xml
          http://jenkins-ci.org/commit/jenkins/b19f4650d7cc146e28398a33ad0625d46991e27f
          Log:
          [FIXED JENKINS-18366] Winstone is now powered by Jetty

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html pom.xml war/pom.xml http://jenkins-ci.org/commit/jenkins/b19f4650d7cc146e28398a33ad0625d46991e27f Log: [FIXED JENKINS-18366] Winstone is now powered by Jetty

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2925
          [FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision b19f4650d7cc146e28398a33ad0625d46991e27f)

          Result = SUCCESS
          kohsuke : b19f4650d7cc146e28398a33ad0625d46991e27f
          Files :

          • war/pom.xml
          • pom.xml
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #2925 [FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision b19f4650d7cc146e28398a33ad0625d46991e27f) Result = SUCCESS kohsuke : b19f4650d7cc146e28398a33ad0625d46991e27f Files : war/pom.xml pom.xml changelog.html

          Could you please add this to the next LTS including --spdy option?

          Ireneusz Makowski added a comment - Could you please add this to the next LTS including --spdy option?

          Dennys Hsieh added a comment -

          I use "java -jar jenkins.war" to run a new 1.536, it works. Ant it extract the war into the temp directory.
          And I stop it by Ctrl-C, I found most files in the above temp are deleted except webapp\WEB-INF\lib.
          Then I try to run it again, I don't see the extract log and I use browser to connect to Jenkins and only see the directory and file under the Jenkins directory.

          Do I need to do any configuration for Jetty 8 ?

          Dennys Hsieh added a comment - I use "java -jar jenkins.war" to run a new 1.536, it works. Ant it extract the war into the temp directory. And I stop it by Ctrl-C, I found most files in the above temp are deleted except webapp\WEB-INF\lib. Then I try to run it again, I don't see the extract log and I use browser to connect to Jenkins and only see the directory and file under the Jenkins directory. Do I need to do any configuration for Jetty 8 ?

          Matthias Rump added a comment - - edited

          I see the same problem as Dennys in 1.537.
          Even if I enforce the JENKINS_HOME environment variable using

          >>java -DJENKINS_HOME=/path/to/jenkins_home/ -jar jenkins.war

          the files are extracted into the users temp directory and jenkins can only be started sucessfully ONCE.

          Every following startup hangs.

          Matthias Rump added a comment - - edited I see the same problem as Dennys in 1.537. Even if I enforce the JENKINS_HOME environment variable using >>java -DJENKINS_HOME=/path/to/jenkins_home/ -jar jenkins.war the files are extracted into the users temp directory and jenkins can only be started sucessfully ONCE. Every following startup hangs.

          Matthias Rump added a comment -

          migration to jetty seem to ignore JENKINS_HOME

          Matthias Rump added a comment - migration to jetty seem to ignore JENKINS_HOME

          Alex Lorenz added a comment -

          Since 536 we have a problem with some of the tests for our self-developed Jenkins plugins.
          It concerns tests which use JenkinsRule class as Junit rule:

          @Rule
          public JenkinsRule jenkinsRule = new JenkinsRule();

          After a test is running (successfully), the Jenkins automatic InjectedTest that checks Jelly files correctness is failling with the following exception:

          Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin]/target/jenkins-for-test/help
          (or /images)
          The full stack trace is further down.
          This happens, even when the only test in in the test class is empty.
          When the respective test is set as Ignored and not run, the build passes successfully and InjectedTest is passing without errors.

          org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest) Time elapsed: 0.005 sec <<< ERROR!
          java.lang.Exception: Failed to initialize exploded war
          at org.jvnet.hudson.test.WarExploder.getExplodedDir(WarExploder.java:49)
          at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492)
          at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469)
          at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312)
          at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133)
          at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49)
          at junit.framework.TestSuite.runTest(TestSuite.java:243)
          at junit.framework.TestSuite.run(TestSuite.java:238)
          at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
          at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
          at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
          at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
          at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
          at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
          at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
          Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin]/target/jenkins-for-test/images
          at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:241)
          at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
          at java.nio.file.Files.delete(Files.java:1071)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at hudson.Util.deleteFile(Util.java:239)
          at hudson.Util.deleteRecursive(Util.java:307)
          at hudson.Util.deleteContentsRecursive(Util.java:204)
          at hudson.Util.deleteRecursive(Util.java:298)
          at hudson.FilePath$12.invoke(FilePath.java:1077)
          at hudson.FilePath$12.invoke(FilePath.java:1074)
          at hudson.FilePath.act(FilePath.java:912)
          at hudson.FilePath.act(FilePath.java:885)
          at hudson.FilePath.deleteRecursive(FilePath.java:1074)
          at org.jvnet.hudson.test.WarExploder.explode(WarExploder.java:96)
          at org.jvnet.hudson.test.WarExploder.<clinit>(WarExploder.java:58)
          at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492)
          at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469)
          at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312)
          at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133)
          at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49)
          at junit.framework.TestSuite.runTest(TestSuite.java:243)
          at junit.framework.TestSuite.run(TestSuite.java:238)
          at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
          at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
          at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
          at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
          at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
          at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
          at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

          Alex Lorenz added a comment - Since 536 we have a problem with some of the tests for our self-developed Jenkins plugins. It concerns tests which use JenkinsRule class as Junit rule: @Rule public JenkinsRule jenkinsRule = new JenkinsRule(); After a test is running (successfully), the Jenkins automatic InjectedTest that checks Jelly files correctness is failling with the following exception: Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin] /target/jenkins-for-test/help (or /images) The full stack trace is further down. This happens, even when the only test in in the test class is empty. When the respective test is set as Ignored and not run, the build passes successfully and InjectedTest is passing without errors. org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest) Time elapsed: 0.005 sec <<< ERROR! java.lang.Exception: Failed to initialize exploded war at org.jvnet.hudson.test.WarExploder.getExplodedDir(WarExploder.java:49) at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492) at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469) at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312) at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133) at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin] /target/jenkins-for-test/images at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:241) at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) at java.nio.file.Files.delete(Files.java:1071) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at hudson.Util.deleteFile(Util.java:239) at hudson.Util.deleteRecursive(Util.java:307) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:298) at hudson.FilePath$12.invoke(FilePath.java:1077) at hudson.FilePath$12.invoke(FilePath.java:1074) at hudson.FilePath.act(FilePath.java:912) at hudson.FilePath.act(FilePath.java:885) at hudson.FilePath.deleteRecursive(FilePath.java:1074) at org.jvnet.hudson.test.WarExploder.explode(WarExploder.java:96) at org.jvnet.hudson.test.WarExploder.<clinit>(WarExploder.java:58) at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492) at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469) at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312) at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133) at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

          Dennys Hsieh added a comment -

          I upgrade my Jenkins and use java -jar jenkins.war to run 1.537, 1.538. It shows following message (it doesn't extract war to any directory). Any work around for it ?

          Running from: D:\Jenkins\jenkins.war
          webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
          2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
          Info: jetty-8.y.z-SNAPSHOT
          2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
          Info: NO JSP Support for , did not find org.apache.jasper.servlet.JspServlet
          2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
          Info: Started SelectChannelConnector@0.0.0.0:80
          2013/11/6 06:42:49 winstone.Logger logInternal
          Info: Winstone Servlet Engine v2.0 running: controlPort=disabled

          Dennys Hsieh added a comment - I upgrade my Jenkins and use java -jar jenkins.war to run 1.537, 1.538. It shows following message (it doesn't extract war to any directory). Any work around for it ? Running from: D:\Jenkins\jenkins.war webroot: EnvVars.masterEnvVars.get("JENKINS_HOME") 2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info Info: jetty-8.y.z-SNAPSHOT 2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info Info: NO JSP Support for , did not find org.apache.jasper.servlet.JspServlet 2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info Info: Started SelectChannelConnector@0.0.0.0:80 2013/11/6 06:42:49 winstone.Logger logInternal Info: Winstone Servlet Engine v2.0 running: controlPort=disabled

          Matthias Rump added a comment -

          to run Jenkins with Jetty instead of Winstone, you need a new Environment Variable "JETTY_HOME", so Jetty know knows where to extract it's stuff.

          for me (on Windows)

          set JETTY_HOME=%JENKINS_HOME%

          did the job.
          HTH

          Matthias Rump added a comment - to run Jenkins with Jetty instead of Winstone, you need a new Environment Variable "JETTY_HOME", so Jetty know knows where to extract it's stuff. for me (on Windows) set JETTY_HOME=%JENKINS_HOME% did the job. HTH

          Dennys Hsieh added a comment -

          JETTY_HOME works for me on 1.538, thanks.

          Dennys Hsieh added a comment - JETTY_HOME works for me on 1.538, thanks.

          Jason Belt added a comment - - edited

          I am seeing something similar to Dennys and Matthias under 1.538 running on Ubuntu 12.04. JENKINS_HOME is set to /var/lib/jenkins and Jenkins is started with the argument --webroot=/var/cache/jenkins/war but Jetty extracts jenkins.war to /tmp/jetty-0.0.0.0-8080-jenkins.war--any-/webapp. It runs fine for awhile but then some process deletes most of the files under the webapp directory (oddly the directories are not deleted). I tried setting the environment variable JETTY_HOME=$JENKINS_HOME but the war file is still extracted to /tmp. Is there a way to get Jetty to extract it to somewhere other than /tmp?

          Jason Belt added a comment - - edited I am seeing something similar to Dennys and Matthias under 1.538 running on Ubuntu 12.04. JENKINS_HOME is set to /var/lib/jenkins and Jenkins is started with the argument --webroot=/var/cache/jenkins/war but Jetty extracts jenkins.war to /tmp/jetty-0.0.0.0-8080-jenkins.war--any-/webapp . It runs fine for awhile but then some process deletes most of the files under the webapp directory (oddly the directories are not deleted). I tried setting the environment variable JETTY_HOME=$JENKINS_HOME but the war file is still extracted to /tmp . Is there a way to get Jetty to extract it to somewhere other than /tmp ?

          Hi Jason,

          We ran into the same issue as you with Ubuntu 11.04. What ended up working was the following:

          1. Create (or choose) a directory where you want to have the WAR be extracted, and make sure the "jenkins" user has R/W access to it. We ended up using $JENKINS_HOME/tmp

          2. Modify the /etc/default/jenkins file to specify the java.io.tmpdir option as an argument to starting Jenkins. For example something like:

          JAVA_ARGS="-Djava.io.tmpdir=$JENKINS_HOME/tmp"

          3. Restart Jenkins

          dev @ doxo.com added a comment - Hi Jason, We ran into the same issue as you with Ubuntu 11.04. What ended up working was the following: 1. Create (or choose) a directory where you want to have the WAR be extracted, and make sure the "jenkins" user has R/W access to it. We ended up using $JENKINS_HOME/tmp 2. Modify the /etc/default/jenkins file to specify the java.io.tmpdir option as an argument to starting Jenkins. For example something like: JAVA_ARGS="-Djava.io.tmpdir=$JENKINS_HOME/tmp" 3. Restart Jenkins

          I have the same error with our Jenkins after an upgrade to 1.539. It extract the war file into our /tmp folder but this one is cleaned by some other process and I can't guarantee that all files will not be deleted... This is a horrible behavior for us and so, it's blocker.

          Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info
          INFO: jetty-8.y.z-SNAPSHOT
          Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info
          INFO: Extract jar:file:/usr/lib/jenkins/jenkins.war!/ to /tmp/jetty-0.0.0.0-8181-jenkins.war-_jenkins-any-/webapp
          Nov 20, 2013 3:29:16 PM org.eclipse.jetty.util.log.JavaUtilLog info
          INFO: NO JSP Support for /jenkins, did not find org.apache.jasper.servlet.JspServlet
          Jenkins home directory: /data/jenkins found at: System.getProperty("JENKINS_HOME")

          @dev, I have try to use your solution and I define another tmp folder for Jenkins but it still extract its war file into our /tmp folder.

          Here an echo of my command line exectuded when I start the service.

          Starting Jenkins
          JAVA_CMD : /usr/java/java6/bin/java -Djava.awt.headless=true -XX:MaxPermSize=512M -Xms512m -Xmx4096m -DJENKINS_HOME=/data/jenkins -jar /usr/lib/jenkins/jenkins.war
          PARAMS : --logfile=/data/logs/jenkins/jenkins.log --webroot=/data/jenkins/war --daemon --httpPort=8181 --ajp13Port=8010 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20 -Djava.io.tmpdir=/data/jenkins/tmp --prefix=/jenkins --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/log/jenkins/access_log

          Thx for any help

          Benjamin Dewez added a comment - I have the same error with our Jenkins after an upgrade to 1.539. It extract the war file into our /tmp folder but this one is cleaned by some other process and I can't guarantee that all files will not be deleted... This is a horrible behavior for us and so, it's blocker. Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info INFO: jetty-8.y.z-SNAPSHOT Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info INFO: Extract jar: file:/usr/lib/jenkins/jenkins.war!/ to /tmp/jetty-0.0.0.0-8181-jenkins.war-_jenkins-any-/webapp Nov 20, 2013 3:29:16 PM org.eclipse.jetty.util.log.JavaUtilLog info INFO: NO JSP Support for /jenkins, did not find org.apache.jasper.servlet.JspServlet Jenkins home directory: /data/jenkins found at: System.getProperty("JENKINS_HOME") @dev, I have try to use your solution and I define another tmp folder for Jenkins but it still extract its war file into our /tmp folder. Here an echo of my command line exectuded when I start the service. Starting Jenkins JAVA_CMD : /usr/java/java6/bin/java -Djava.awt.headless=true -XX:MaxPermSize=512M -Xms512m -Xmx4096m -DJENKINS_HOME=/data/jenkins -jar /usr/lib/jenkins/jenkins.war PARAMS : --logfile=/data/logs/jenkins/jenkins.log --webroot=/data/jenkins/war --daemon --httpPort=8181 --ajp13Port=8010 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20 -Djava.io.tmpdir=/data/jenkins/tmp --prefix=/jenkins --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/log/jenkins/access_log Thx for any help

          Hi Benjamin,

          Looks like you are passing the "-Djava.io.tmpdir" argument to the Servlet container, not to the Java runtime. That "-D" argument needs to be a part of JAVA_CMD.

          dev @ doxo.com added a comment - Hi Benjamin, Looks like you are passing the "-Djava.io.tmpdir" argument to the Servlet container, not to the Java runtime. That "-D" argument needs to be a part of JAVA_CMD.

          Alex Ouzounis added a comment - - edited

          Hi,

          Just to add my observations here.

          Following the instructions from dev #comment-189758 the issue is gone for my Jenkins 1.539 installation.
          The only thing to add is make sure that the JENKINS_HOME var is defined before the JAVA_ARGS var.

          Alex

          Alex Ouzounis added a comment - - edited Hi, Just to add my observations here. Following the instructions from dev #comment-189758 the issue is gone for my Jenkins 1.539 installation. The only thing to add is make sure that the JENKINS_HOME var is defined before the JAVA_ARGS var. Alex

          @dev, Oh my god, you right ! I define this property into the JENKINS_ARGS and no JAVA_ARGS. I fix this error tomorrow and I keep you aware of the result. Thx

          Benjamin Dewez added a comment - @dev, Oh my god, you right ! I define this property into the JENKINS_ARGS and no JAVA_ARGS. I fix this error tomorrow and I keep you aware of the result. Thx

          Hi,
          I am having trouble getting the Jenkins webpage up using a Solaris 10 server (JRE 1.6.0_26-b03).
          The log shows Jenkins started successfully (Jenkins is fully up and running).
          However when I try to connect using a web browser (tried IE and Firefox from Jenkins server localhost and remote machines) it hangs indefinitely.
          Checking netstat shows the connection is ESTABLISHED.
          All versions of Jenkins prior to 1.535 work perfectly under Solaris 10 and no versions after 1.534 work.
          So I can only assume it was the introduction of Jetty in 1.535 that has caused this issue.
          Cheers,
          Josh

          Joshua Wherrett added a comment - Hi, I am having trouble getting the Jenkins webpage up using a Solaris 10 server (JRE 1.6.0_26-b03). The log shows Jenkins started successfully (Jenkins is fully up and running). However when I try to connect using a web browser (tried IE and Firefox from Jenkins server localhost and remote machines) it hangs indefinitely. Checking netstat shows the connection is ESTABLISHED. All versions of Jenkins prior to 1.535 work perfectly under Solaris 10 and no versions after 1.534 work. So I can only assume it was the introduction of Jetty in 1.535 that has caused this issue. Cheers, Josh

          S Stack added a comment -

          Solaris 10: CLI broken at Jenkins 1.535+

          @Josh, we're running Solaris 10 and while the Jenkins UI appears to work just fine in 1.535 and above, the CLI hangs:

          java -jar 1.538/WEB-INF/jenkins-cli.jar -s http://cits.icc.intcx.net:8080 version
          
          Exception in thread "main" java.net.SocketTimeoutException: connect timed out
                  at java.net.PlainSocketImpl.socketConnect(Native Method)
                  at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
                  at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
                  at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
                  at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385)
                  at java.net.Socket.connect(Socket.java:546)
                  at hudson.cli.CLI.connectViaCliPort(CLI.java:211)
                  at hudson.cli.CLI.<init>(CLI.java:134)
                  at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
                  at hudson.cli.CLI._main(CLI.java:469)
                  at hudson.cli.CLI.main(CLI.java:384)
          

          Observations

          • Jetty is unpacked to the -Djava.io.tmpdir directory regardless of setting -DJETTY_HOME=/some/dir/.
          • JNLP port is enabled; setting this to either random or a fixed port did not address the CLI timeout.

          S Stack added a comment - Solaris 10: CLI broken at Jenkins 1.535+ Per https://issues.jenkins-ci.org/browse/JENKINS-20128?focusedCommentId=188660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-188660 , CLI works fine up to and including 1.534 @Josh, we're running Solaris 10 and while the Jenkins UI appears to work just fine in 1.535 and above, the CLI hangs: java -jar 1.538/WEB-INF/jenkins-cli.jar -s http: //cits.icc.intcx.net:8080 version Exception in thread "main" java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:546) at hudson.cli.CLI.connectViaCliPort(CLI.java:211) at hudson.cli.CLI.<init>(CLI.java:134) at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72) at hudson.cli.CLI._main(CLI.java:469) at hudson.cli.CLI.main(CLI.java:384) Observations Jetty is unpacked to the -Djava.io.tmpdir directory regardless of setting -DJETTY_HOME=/some/dir/ . JNLP port is enabled; setting this to either random or a fixed port did not address the CLI timeout.

          Jesse Glick added a comment -

          @maschuru

          migration to jetty seem to ignore JENKINS_HOME

          File a separate bug (with a JIRA link) please. Do not reopen this one.

          Jesse Glick added a comment - @maschuru migration to jetty seem to ignore JENKINS_HOME File a separate bug (with a JIRA link) please. Do not reopen this one.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          pom.xml
          war/pom.xml
          http://jenkins-ci.org/commit/jenkins/2394c0cd0e233449c85da3bc75628420a2b07a05
          Log:
          [FIXED JENKINS-18366] Winstone is now powered by Jetty

          (cherry picked from commit b19f4650d7cc146e28398a33ad0625d46991e27f)

          Conflicts:
          changelog.html
          war/pom.xml

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: pom.xml war/pom.xml http://jenkins-ci.org/commit/jenkins/2394c0cd0e233449c85da3bc75628420a2b07a05 Log: [FIXED JENKINS-18366] Winstone is now powered by Jetty (cherry picked from commit b19f4650d7cc146e28398a33ad0625d46991e27f) Conflicts: changelog.html war/pom.xml

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3787
          [FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision 2394c0cd0e233449c85da3bc75628420a2b07a05)

          Result = SUCCESS
          jesse glick : 2394c0cd0e233449c85da3bc75628420a2b07a05
          Files :

          • war/pom.xml
          • pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #3787 [FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision 2394c0cd0e233449c85da3bc75628420a2b07a05) Result = SUCCESS jesse glick : 2394c0cd0e233449c85da3bc75628420a2b07a05 Files : war/pom.xml pom.xml

            Unassigned Unassigned
            md_5 Michael D
            Votes:
            10 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: