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

FilePath.validateAntFileMask too slow for /configure

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
    • Environment:
      1.371
    • Similar Issues:

      Description

      I have been waiting about half an hour for a job to finish:

      Archiving artifacts
      Recording test results
      

      Thread dumps show some activity in one thread in JUnitParser$ParseResultCallable.invoke, which is to be expected. There are also several threads running DirectoryBrowserSupport$ChildPathBuilder.invoke, which is unwanted (perhaps some rogue clients looking at workspace), but not much to be done except to time out this class of HTTP requests.

      More disturbing is 11 threads running FilePath$34.invoke, which is FilePath.validateAntFileMask (ought to be refactored into a named class for diagnostic purposes). The only reason I can think of why this code should be running is that around an hour ago I went to the /configure screen of 11 jobs and made a minor change. Apparently Hudson is still validating the archiver or test result patterns for these jobs' workspaces, long after the configure screen was closed! Note that the workspace for each job is big (tens of thousands of files), so doing any kind of scan over it is going to be quite slow. A typical thread from the /systemInfo dump:

      "pool-1-thread-646" Id=9659 Group=main RUNNABLE
      	at org.apache.tools.ant.util.VectorSet.doAdd(VectorSet.java:80)
      	-  locked org.apache.tools.ant.util.VectorSet@51043b57
      	at org.apache.tools.ant.util.VectorSet.addElement(VectorSet.java:91)
      	-  locked org.apache.tools.ant.util.VectorSet@51043b57
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1236)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1259)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1259)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1259)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1259)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1259)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1184)
      	at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1146)
      	at org.apache.tools.ant.DirectoryScanner.checkIncludePatterns(DirectoryScanner.java:928)
      	at org.apache.tools.ant.DirectoryScanner.scan(DirectoryScanner.java:882)
      	-  locked org.apache.tools.ant.DirectoryScanner@42a238b6
      	at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:490)
      	at hudson.FilePath$34.invoke(FilePath.java:1656)
      	at hudson.FilePath$34.invoke(FilePath.java:1615)
      	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1899)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:104)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:270)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      	at java.lang.Thread.run(Thread.java:619)
      
      	Number of locked synchronizers = 1
      	- java.util.concurrent.locks.ReentrantLock$NonfairSync@283956e7
      

      1. Any kind of validation must be aborted once the config screen is submitted.

      2. Doing a full workspace scan just to provide an error hint about a field you are not even changing is unacceptable.

      3. The patterns in question are of the form nbbuild/*.zip or */build/test/*/results/*.xml, i.e. they do not use the ** wildcard sequence, so there is no excuse for them to take this long to run to begin with. Using /usr/bin/ls with the same pattern gives an answer essentially immediately (around 20 matches).

        Attachments

        1. config.xml
          1 kB
        2. jenkins7214.hg
          3 kB
        3. td.txt
          134 kB
        4. workaround7214.hpi
          5 kB

          Issue Links

            Activity

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                jglick Jesse Glick
              • Votes:
                2 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: