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

safeRestart waits forever and does not restart Hudson

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • core
    • None
    • Debian Linux
      java version "1.6.0_18"
      OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-1)
      OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)

    Description

      After change from Hudson ver. 1.358 to 1.359 the /safeRestart command will only bring Hudson to say "Hudson is being shut down", but the restart is not performed, although no jobs seem to be running (updates complete, no builds planned). The /restart command is still working properly.

      Attachments

        Issue Links

          Activity

            mindless Alan Harder added a comment -

            I don't see any problem in current svn, running in jetty.. not sure what environment factors are important here.
            Can someone who sees this problem see how many of the log messages added in http://jenkins-ci.org/commit/31484 show up before things lock up?

            mindless Alan Harder added a comment - I don't see any problem in current svn, running in jetty.. not sure what environment factors are important here. Can someone who sees this problem see how many of the log messages added in http://jenkins-ci.org/commit/31484 show up before things lock up?
            emmulator emmulator added a comment -

            Here is a section of our main HUDSON_HOME/stderr.log from the last time we bounced the Master. It was unresponsive to further http requests during this quieting down period.

            emmulator emmulator added a comment - Here is a section of our main HUDSON_HOME/stderr.log from the last time we bounced the Master. It was unresponsive to further http requests during this quieting down period.
            mindless Alan Harder added a comment -

            ah! after some earlier refactor safeRestart started calling doQuietDown.. this method is synchronized, so it has locked out the main Hudson object the entire time it waits for shutdown (ie, exactly the behavior you describe)..

            mindless Alan Harder added a comment - ah! after some earlier refactor safeRestart started calling doQuietDown.. this method is synchronized, so it has locked out the main Hudson object the entire time it waits for shutdown (ie, exactly the behavior you describe)..

            Code changed in hudson
            User: : mindless
            Path:
            trunk/hudson/main/core/src/main/java/hudson/model/Hudson.java
            trunk/www/changelog.html
            http://jenkins-ci.org/commit/32805
            Log:
            [FIXED JENKINS-6649] doQuietDown was sychronized, so safeRestart (calling doQuietDown
            in blocking mode since 1.361) was locking Hudson object until all jobs complete!
            Now synchronize just to set isQuietingDown flag, but not while blocking.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/model/Hudson.java trunk/www/changelog.html http://jenkins-ci.org/commit/32805 Log: [FIXED JENKINS-6649] doQuietDown was sychronized, so safeRestart (calling doQuietDown in blocking mode since 1.361) was locking Hudson object until all jobs complete! Now synchronize just to set isQuietingDown flag, but not while blocking.
            emmulator emmulator added a comment -

            I just upgraded and wanted to post confirmation that indeed this is working as before – thanks!

            emmulator emmulator added a comment - I just upgraded and wanted to post confirmation that indeed this is working as before – thanks!

            People

              mindless Alan Harder
              hendrik_millner hendrik_millner
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: