Maven surefire plugin hangs forever

Question

My project install was perfectly fine until yesterday but today my install gets stuck at the following,

Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)

Java version: 1.6.0_20

[INFO] Surefire report directory: C:\\Perforce\\project-name\\target\\surefire-reports

Basically after this line the install does not proceed at all. Any thoughts?

1. I have tried mvn -X and I get the same thing.
2. I have even upgraded to version 2.6 the latest and still get the same issue
3. I have ensured that there are no debug options ie, the JVM is not waiting for any debugger to attach(-Xdebug options)

Answer 1

使用jstack进行正确进程的线程转储并提交问题

Answer 2

I passed the forkMode=never and now I noticed that one of the tests was not starting up at all. The reason was that it was using a ehcache and stored entries in the "java.io.tmpdir" directory which was my user's temporary directory.

The system also started being slow from today. Then I noticed that my C:/users/../AppData/Local/Temp folder had about 2 million files most of them either p4ticket234234.txt or Visual studio log files.

Once I cleared these log files, my build went successful. A jconsole or some thread dump would have more indicated the same I think.

Answer 3

Surefire waits for all non-daemon threads in your application to finish. It's easy to miss one or another. For example make sure to call the shutdown method on your Executors if you use any. If you do thread handling on your own you basically have to either make them daemon threads or make sure they terminate. A thread dump might help to spot the lingering threads.

Answer 4

使用JDK中的jps，jstack或jvisualvm工具获取进程及其线程转储的列表。

Answer 5

I had the same problem. All of a sudden my "mvn test" was hanging seemingly forever and the related org.apache.maven.surefire.booter.ForkedBooter process was taking 1.7GB! After much investigation it turns out that the problem was that I had deleted a class that was being instantiated by spring-core as a spring bean within the spring XML configuration. Once I removed the element corresponding to the deleted class from the spring XML configuration all was well. This seems like a bug in spring and surefire usage where no reasonable warning or error is produced.