Maven безошибочного плагин висит навсегда

Question

Моего проекта установки было прекрасно до вчерашнего дня, но сегодня моя установки застревает в следующем,

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

Java версия: 1.6.0_20

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

в основном после этой линии установки не происходит вообще. Есть предположения?

1. Я пробовал mvn -X, и я получаю то же самое.
2. Я даже обновлен до версии 2.6 последних и до сих пор получить тот же вопрос
3. я гарантировал, что нет никаких вариантов отладки не то есть, виртуальная машина не ждут любого отладчика для присоединения (-Xdebug опции)

Answer 1

Я передал forkMode = никогда, и теперь я заметил, что один из тестов не запускался вообще. Причина заключалась в том, что он использовал ehcache и хранил записи в каталоге «java.io.tmpdir», который был временным каталогом моего пользователя.

Система также начала замедляться с сегодняшнего дня. Затем я заметил, что у моей папки C:/users /../ AppData/Local/Temp было около 2 миллионов файлов, большинство из которых либо p4ticket234234.txt, либо файлы журналов Visual Studio.

Как только я очистил эти файлы журналов, моя сборка прошла успешно. Я думаю, что jconsole или какой-то нить с нитью будут отображаться так же.

Answer 2

Сделать нить дамп правильного процесса с использованием jstack и представить Спорный вопрос

Answer 3

Surefire ждет для всех потоков без демона в вашем приложении, чтобы закончить. Легко пропустить то или другое. Например, не забудьте вызвать метод shutdown на вашем Executors, если вы его используете. Если вы выполняете обработку потоков самостоятельно, вам в основном нужно либо сделать их daemon потоками, либо убедиться, что они завершатся. Дамп потока может помочь обнаружить затяжные нити.

Answer 4

Используйте jps, jstack или jvisualvm инструменты от JDK, чтобы получить список процессов и их дампы потоков.

Answer 5

У меня была та же проблема. Внезапно мой «тест mvn» висел, казалось бы, навсегда, и связанный с ним процесс org.apache.maven.surefire.booter.ForkedBooter принимал 1.7GB! После долгих исследований выясняется, что проблема заключалась в том, что я удалил класс, созданный пружинным ядром в качестве весеннего компонента в рамках весенней конфигурации XML. Как только я удалил элемент, соответствующий удаленному классу из весенней конфигурации XML, все было хорошо. Это кажется ошибкой весной и уверенным использованием, когда не возникает разумного предупреждения или ошибки.