• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • None
    • Platform: PC, OS: Windows XP

      The system is running on:
      Xeon X5482 @ 3.2Ghz, Hyper-threading disabled
      8Gb RAM
      Windows XP x64
      Hudson 1.323

      It is configured to poll SVN once a minute for 2 projects. The authentication is
      done via active-directory.

      After a few days of running, Java start to use the whole CPU power available.
      Investigation showed up that there are 4 threads (one per core) running all the
      time. All these threads are having the same dump:

      "RequestHandlerThread0" daemon prio=6 tid=0x0000000009b10000 nid=0x54574
      runnable [0x000000000c51f000..0x000000000c51f860]
      java.lang.Thread.State: RUNNABLE
      at java.util.HashMap.put(HashMap.java:376)
      at java.util.HashSet.add(HashSet.java:200)
      at winstone.WinstoneSession.addUsed(WinstoneSession.java:112)
      at winstone.WinstoneRequest.getSession(WinstoneRequest.java:1320)
      at
      winstone.auth.FormAuthenticationHandler.validatePossibleAuthenticationResponse(FormAuthenticationHandler.java:216)
      at
      winstone.auth.BaseAuthenticationHandler.processAuthentication(BaseAuthenticationHandler.java:85)
      at
      winstone.auth.FormAuthenticationHandler.processAuthentication(FormAuthenticationHandler.java:99)
      at
      winstone.RequestDispatcher.continueAfterSecurityCheck(RequestDispatcher.java:349)
      at winstone.RequestDispatcher.forward(RequestDispatcher.java:323)
      at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
      at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
      at java.lang.Thread.run(Thread.java:619)

          [JENKINS-4512] Hudson consumes 100% CPU

          mdonohue added a comment -

          move subcomponent to 'core'

          mdonohue added a comment - move subcomponent to 'core'

          yzach added a comment -

          This issue never happens when running under tomcat.

          yzach added a comment - This issue never happens when running under tomcat.

          skyhawke added a comment -

          Not having looked at the code, might this be a static instance of a HashSet? This would easily trigger http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457 which I have seen numerous times in our applications, usually occurring after weeks of server uptime.

          skyhawke added a comment - Not having looked at the code, might this be a static instance of a HashSet? This would easily trigger http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457 which I have seen numerous times in our applications, usually occurring after weeks of server uptime.

          yzach added a comment - - edited

          It really looks like the mentioned bug. Our dual-core XP x32 with the same Hudson setup, is running for 3 months and is rock stable (we owe you thanks for that .
          Probably this bug should be moved to the Winstone project.
          Also maybe it should be of a lesser priority, as running Hudson on another container completely solves the problem.

          yzach added a comment - - edited It really looks like the mentioned bug. Our dual-core XP x32 with the same Hudson setup, is running for 3 months and is rock stable (we owe you thanks for that . Probably this bug should be moved to the Winstone project. Also maybe it should be of a lesser priority, as running Hudson on another container completely solves the problem.

          ebann added a comment - - edited

          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457 is about get() no ?
          Here the trace shows put() hanging.

          Isn't it related to http://issues.jenkins-ci.org/browse/JENKINS-5119 ?

          Because in Hashmap code i can see that the hanging line is:

          for (Entry<K,V> e = table[i]; e != null; e = e.next) {
          Object k;
          >>>> if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {

          Which reminds me of a performance problem when you have A_LOT of similar objects in a hashmap.

          I mean, if the session are not cleaned, maybe there is so many sessions and/or performing equals() is so cpu consuming that the system is getting slow ?

          Anyway, 5119 has been fixed, is it possible to check it again with a fixed version ?

          ebann added a comment - - edited http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457 is about get() no ? Here the trace shows put() hanging. Isn't it related to http://issues.jenkins-ci.org/browse/JENKINS-5119 ? Because in Hashmap code i can see that the hanging line is: for (Entry<K,V> e = table [i] ; e != null; e = e.next) { Object k; >>>> if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { Which reminds me of a performance problem when you have A_LOT of similar objects in a hashmap. I mean, if the session are not cleaned, maybe there is so many sessions and/or performing equals() is so cpu consuming that the system is getting slow ? Anyway, 5119 has been fixed, is it possible to check it again with a fixed version ?

          yzach added a comment -

          In order to avoid this problem, we have installed another OS on our servers. So basically I have no environment to reproduce it.

          yzach added a comment - In order to avoid this problem, we have installed another OS on our servers. So basically I have no environment to reproduce it.

          kutzi added a comment -

          Assuming that this is the same as JENKINS-5119 and therefore fixed.

          kutzi added a comment - Assuming that this is the same as JENKINS-5119 and therefore fixed.

            Unassigned Unassigned
            yzach yzach
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: