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

FilePath.validateAntFileMask too slow for /configure

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • 1.371

      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).

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

          [JENKINS-7214] FilePath.validateAntFileMask too slow for /configure

          Jesse Glick created issue -

          Dave Landers added a comment - - edited

          My workaround for this is a plugin filter that blocks the validation:

          @Extension
          public class ValidatorKiller extends Plugin implements Filter
          {
              // Requests that call FilePath.validateFileMask:
              //  .../descriptorByName/hudson.tasks.ArtifactArchiver/checkArtifacts
              //  .../descriptorByName/hudson.tasks.junit.JUnitResultArchiver/checkTestResults
              //  .../descriptorByName/Fingerprinter/check
          
              private static final Pattern checkPattern = Pattern.compile("/descriptorByName/"
                      + "(?:hudson\\.tasks\\.ArtifactArchiver/checkArtifacts|"
                      + "hudson\\.tasks\\.junit\\.JUnitResultArchiver/checkTestResults|"
                      + "Fingerprinter/check)$" );
          
              private static final Logger logger = Logger.getLogger( ValidatorKiller.class.getName() );
          
              @Override
              public void start() throws ServletException
              {
                  logger.info( "Installing ValidatorKiller filter" );
                  PluginServletFilter.addFilter(this);
              }
          
              @Override
              public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
              {
                  if ( request instanceof HttpServletRequest )
                  {
                      HttpServletRequest hrq = (HttpServletRequest) request;
                      if ( "GET".equals( hrq.getMethod() ) )
                      {
                          Matcher matcher = checkPattern.matcher( hrq.getRequestURI() );
                          if (matcher.find())
                          {
                              logger.info( "Skipping request " + hrq.getRequestURI() );
                              return;
                          }
                      }
                  }
                  chain.doFilter(request, response);
              }
              @Override public void init(FilterConfig filterConfig) throws ServletException { }
              @Override public void destroy() { }
          }
          

          EDIT: Cleaned up grouping in regex.

          Dave Landers added a comment - - edited My workaround for this is a plugin filter that blocks the validation: @Extension public class ValidatorKiller extends Plugin implements Filter { // Requests that call FilePath.validateFileMask: // .../descriptorByName/hudson.tasks.ArtifactArchiver/checkArtifacts // .../descriptorByName/hudson.tasks.junit.JUnitResultArchiver/checkTestResults // .../descriptorByName/Fingerprinter/check private static final Pattern checkPattern = Pattern.compile( "/descriptorByName/" + "(?:hudson\\.tasks\\.ArtifactArchiver/checkArtifacts|" + "hudson\\.tasks\\.junit\\.JUnitResultArchiver/checkTestResults|" + "Fingerprinter/check)$" ); private static final Logger logger = Logger.getLogger( ValidatorKiller. class. getName() ); @Override public void start() throws ServletException { logger.info( "Installing ValidatorKiller filter" ); PluginServletFilter.addFilter( this ); } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if ( request instanceof HttpServletRequest ) { HttpServletRequest hrq = (HttpServletRequest) request; if ( "GET" .equals( hrq.getMethod() ) ) { Matcher matcher = checkPattern.matcher( hrq.getRequestURI() ); if (matcher.find()) { logger.info( "Skipping request " + hrq.getRequestURI() ); return ; } } } chain.doFilter(request, response); } @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void destroy() { } } EDIT: Cleaned up grouping in regex.

          Jesse Glick added a comment -

          Clever. Do you plan to release this? I guess as a workaround it is not really appropriate for publishing.

          BTW your regexp is not quite right: the | should be inside (...), not outside.

          Jesse Glick added a comment - Clever. Do you plan to release this? I guess as a workaround it is not really appropriate for publishing. BTW your regexp is not quite right: the | should be inside (...) , not outside.

          Jesse Glick added a comment -

          Typical thread dump after a freeze ("GC overhead limit exceeded" in log).

          Jesse Glick added a comment - Typical thread dump after a freeze ("GC overhead limit exceeded" in log).
          Jesse Glick made changes -
          Attachment New: td.txt [ 20561 ]

          Jesse Glick added a comment -

          Apparently functional plugin binary, as well as Mercurial bundle of sources used to build it.

          Jesse Glick added a comment - Apparently functional plugin binary, as well as Mercurial bundle of sources used to build it.
          Jesse Glick made changes -
          Attachment New: jenkins7214.hg [ 20562 ]
          Attachment New: workaround7214.hpi [ 20563 ]
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-15223 [ JENKINS-15223 ]
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

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

              Created:
              Updated:
              Resolved: