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

NumberFormatException in p4 changes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Duplicate
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: Windows XP
    • Similar Issues:

      Description

      [workspace] $ p4 changes -m 25 //depot/main/Foo/...
      FATAL: For input string: "too"
      java.lang.NumberFormatException: For input string: "too"
      at java.lang.NumberFormatException.forInputString(Unknown Source)
      at java.lang.Integer.parseInt(Unknown Source)
      at java.lang.Integer.<init>(Unknown Source)
      at
      com.tek42.perforce.parse.Changes.getChangeNumbersToForSinglePath(Changes.java:217)
      at com.tek42.perforce.parse.Changes.getChangeNumbersTo(Changes.java:171)
      at com.tek42.perforce.parse.Changes.getChangeNumbersTo(Changes.java:127)
      at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:288)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:574)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:251)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:225)
      at hudson.model.Run.run(Run.java:778)
      at hudson.model.Build.run(Build.java:85)
      at hudson.model.ResourceController.execute(ResourceController.java:70)
      at hudson.model.Executor.run(Executor.java:85)

      The actual string results of this command are as follows:
      Request too large (over 700000); see 'p4 help maxresults'.

      Exceptions such as this should be caught and handled.
      In this case, the depot path will have to be broken up.

      Strip the final ... from the view path given, and replace it with a *. This will
      then be an argument to p4 dirs

      p4 dirs //depot/main/Foo/*

      This will then return a list of nested paths that stand a better chance of
      satisfying the perforce limits.

      This is a blocking issue for me, as I am currently unable to sync a project to
      even get hudson to start building my project.

        Attachments

          Activity

          Hide
          yodee yodee added a comment -

          It looks like we have one more problem. The P4 plugin deletes the view and hence further builds are not initiated. Could you please let me know when the view itself change and why the plugin edits the view and leave it in the in-consistent state.

          Show
          yodee yodee added a comment - It looks like we have one more problem. The P4 plugin deletes the view and hence further builds are not initiated. Could you please let me know when the view itself change and why the plugin edits the view and leave it in the in-consistent state.
          Hide
          yodee yodee added a comment -

          I need to look at it end of this month. If some one interested in fixing the "view" change issue please go ahead. But please assign this issue to yourself first.

          Show
          yodee yodee added a comment - I need to look at it end of this month. If some one interested in fixing the "view" change issue please go ahead. But please assign this issue to yourself first.
          Hide
          rpetti Rob Petti added a comment -

          The view spec isn't left in an inconsistent state, the workspace is. And what do you mean by "deletes the view"? The plugin doesn't delete views at any time.

          The issue arises when the USER changes the view spec, either in the job config if the plugin is configured to handle it, or manually when the job isn't configured to manage the view. Consider the following example:

          The user adds a new line to the view spec, for example:

          //depot/project/somefile.c
          

          Now lets say that the last revision that was synced was 100, and we're currently at 110 in the depot. With your changes, the perforce plugin calls:

          p4 sync //workspace/...@100,@110
          

          This will work fine, as long as the file has been changed between those two revisions. If it has not been changed between those two revisions, then the file will not get synced to the workspace. This leaves the workspace in an inconsistent sync state, which is unacceptable.

          The way I see it, performing a

          p4 sync //workspace/...@110
          

          Is a perfectly reasonable thing to ask the perforce server to do. If it doesn't let you do this, then your limits are set far too low, and must be increased.

          Show
          rpetti Rob Petti added a comment - The view spec isn't left in an inconsistent state, the workspace is. And what do you mean by "deletes the view"? The plugin doesn't delete views at any time. The issue arises when the USER changes the view spec, either in the job config if the plugin is configured to handle it, or manually when the job isn't configured to manage the view. Consider the following example: The user adds a new line to the view spec, for example: //depot/project/somefile.c Now lets say that the last revision that was synced was 100, and we're currently at 110 in the depot. With your changes, the perforce plugin calls: p4 sync //workspace/...@100,@110 This will work fine, as long as the file has been changed between those two revisions . If it has not been changed between those two revisions, then the file will not get synced to the workspace . This leaves the workspace in an inconsistent sync state, which is unacceptable. The way I see it, performing a p4 sync //workspace/...@110 Is a perfectly reasonable thing to ask the perforce server to do. If it doesn't let you do this, then your limits are set far too low, and must be increased.
          Hide
          rpetti Rob Petti added a comment -

          Also, wiping out the workspace and performing a force sync also exhibits this behavior; Only files changed between builds will get synced correctly.

          Show
          rpetti Rob Petti added a comment - Also, wiping out the workspace and performing a force sync also exhibits this behavior; Only files changed between builds will get synced correctly.
          Hide
          rpetti Rob Petti added a comment -

          JENKINS-6341 better describes this issue.

          Show
          rpetti Rob Petti added a comment - JENKINS-6341 better describes this issue.

            People

            • Assignee:
              yodee yodee
              Reporter:
              folkstone42 folkstone42
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: