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

Bug in Channel class or communication to slaves - Accurev plugin fails when getting list of streams

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Incomplete
    • Component/s: other
    • Labels:
      None
    • Environment:
      Hudson 1.378 all the way to 1.395.
      Accurev-Hudson Plugin 0.6.12-SNAPSHOT
      Ubuntu 10.4 host, Java 1.6
    • Similar Issues:

      Description

      Although this issue manifests itself with the Accurev plugin, I believe this is an issue with the Hudson core because we have found that downgrading the version of Hudson fixes the problem, but the Accurev plugin version can remain the same. This implies to me something changed in Hudson to cause this problem.

      We get the following error when we try to compile our software using Jenkins 1.395 and Accurev Plugin 0.6.12-SNAPSHOT. This happens on our build slaves (nodes), but not on the Hudson master.

      I have run the "failing" command on the command-line and I do not see any syntax errors in the XML output. It seems as though the long list of streams (we have many, many) is overflowing the XML parser.

      I also wrote a small test around the accurev-plugin code that loaded the XML stream from file, and this code worked correctly. This leads me to believe there is an issue with the Channel implementation to the slave node, since it seems to work correctly on the Master.

      We found that downgrading to 1.380 exhibited a slightly different, but still fatal error, and by downgrading to 1.377, the problem went away completely.

      Started by user anonymous
      Building remotely on flawlessvm3
      Authenticating with Accurev server...
      Purging workspace...
      Workspace purged.
      [Josh_Framework_maven3] $ accurev login -H accurev.XXXX.com:5050 arevjira ********
      Authentication completed successfully.
      Getting a list of streams...
      [Josh_Framework_maven3] $ accurev show -H accurev.XXXX.com:5050 -fx -p software streams
      java.io.EOFException: no more data available - expected end tags </stream></streams> to close start tag <stream> from line 22935 and start tag <streams> from line 1, parser stopped on TEXT seen ...<stream\n      name="project_stream_name... @22935:44
      	at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3035)
      	at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
      	at org.xmlpull.mxp1.MXParser.parseAttribute(MXParser.java:2026)
      	at org.xmlpull.mxp1.MXParser.parseStartTag(MXParser.java:1799)
      	at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1127)
      	at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
      	at hudson.plugins.accurev.AccurevSCM.getStreams(AccurevSCM.java:752)
      	at hudson.plugins.accurev.AccurevSCM.checkout(AccurevSCM.java:295)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
      	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:499)
      	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:415)
      	at hudson.model.Run.run(Run.java:1362)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:145)
      Recording test results
      Notifying upstream projects of job completion
      Finished: FAILURE
      

      When we downgraded to Hudson 1.380, we get this similar, but different error instead:

      [Josh_SmokeTests_maven3] $ accurev hist -H accurev.kivasystems.com:5050 -fx -p software -s mhs_Josh -t now.1 -k add
      getTimeOfLatestTransaction failed when checking the stream mhs_Josh for changes with transaction type add
      java.io.EOFException: input contained no data
      	at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
      	at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
      	at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
      	at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
      	at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
      	at hudson.plugins.accurev.AccurevSCM.getLatestTransaction(AccurevSCM.java:980)
      	at hudson.plugins.accurev.AccurevSCM.checkStreamForChanges(AccurevSCM.java:896)
      	at hudson.plugins.accurev.AccurevSCM.checkout(AccurevSCM.java:521)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1082)
      	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
      	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
      	at hudson.model.Run.run(Run.java:1280)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:140)
      

      When we finally downgraded all the way to Hudson 1.377, the problem went away completely.

      I submitted a matching issue on the hudson-ci.org issue tracker, here: http://issues.hudson-ci.org/browse/HUDSON-8703

        Attachments

          Issue Links

            Activity

            Hide
            jpollak jpollak added a comment -

            I believe this is the same issue, however it doesn't seem to be related to the accurev plugin so much as the Jenkins core.

            Show
            jpollak jpollak added a comment - I believe this is the same issue, however it doesn't seem to be related to the accurev plugin so much as the Jenkins core.
            Hide
            pjdarton pjdarton added a comment -

            I concurr - it does sound like this is exactly the same issue as I reported in JENKINS-8273, except this report provides a lot more detail as to where the underlying fault lies (I just assumed it was a problem with AccuRev but it seems that, this time, AccuRev isn't the problem).

            There are similar issues relating to master/slave comms when fetching coverage data, e.g. JENKINS-7951, which leads me to think that there's an underlying master-slave communications problem which then shows up when plugins rely on it.

            Show
            pjdarton pjdarton added a comment - I concurr - it does sound like this is exactly the same issue as I reported in JENKINS-8273 , except this report provides a lot more detail as to where the underlying fault lies (I just assumed it was a problem with AccuRev but it seems that, this time, AccuRev isn't the problem). There are similar issues relating to master/slave comms when fetching coverage data, e.g. JENKINS-7951 , which leads me to think that there's an underlying master-slave communications problem which then shows up when plugins rely on it.
            Hide
            pjdarton pjdarton added a comment -

            Since upgrading to a later version of Jenkins (1.409) which has the JENKINS-7951 / JENKINS-7836 fix in it, I've not seen this problem again.

            I believe that this issue was in the Jenkins core to do with master/slave comms, and fixing JENKINS-7951 / JENKINS-7836 fixed this one.

            I would suggest that this can be closed.

            Show
            pjdarton pjdarton added a comment - Since upgrading to a later version of Jenkins (1.409) which has the JENKINS-7951 / JENKINS-7836 fix in it, I've not seen this problem again. I believe that this issue was in the Jenkins core to do with master/slave comms, and fixing JENKINS-7951 / JENKINS-7836 fixed this one. I would suggest that this can be closed.
            Hide
            evernat evernat added a comment -

            It was suggested that this issue could be closed because it was probably fixed with other issues as said above.

            No response from the reporter so closing.
            Please reopen if needed.

            Show
            evernat evernat added a comment - It was suggested that this issue could be closed because it was probably fixed with other issues as said above. No response from the reporter so closing. Please reopen if needed.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jpollak jpollak
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: