-
Bug
-
Resolution: Fixed
-
Major
-
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).
- depends on
-
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Closed
-