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

    • Icon: Bug Bug
    • Resolution: Incomplete
    • Icon: Major Major
    • other
    • None
    • Hudson 1.378 all the way to 1.395.
      Accurev-Hudson Plugin 0.6.12-SNAPSHOT
      Ubuntu 10.4 host, Java 1.6

      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

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

          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.

          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.

          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.

          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.

          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.

          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.

          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.

          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.

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

              Created:
              Updated:
              Resolved: