Sporadic java.lang.NoClassDefFoundError в Scala

Question

У нас есть странная проблема. Мы используем инструмент автоматического тестирования. DSL был реализован в Scala. Система, которую мы тестируем с помощью этого инструмента, была написана на Java, а интерфейс между этими двумя компонентами - RMI. Действительно, интерфейсная часть автоматического тестового инструмента также является Java (остальное - Scala). Мы полностью контролируем исходный код этих компонентов.

У нас уже есть величина тысяч тестовых случаев. Мы выполняем эти тесты автоматически каждый раз, используя Jenkins на сервере Linux. Проблема в том, что мы спорадически получаем исключение java.lang.NoClassDefFoundError. Обычно это происходит при попытке доступа к артефактам Java из кода Scala.

Если мы выполняем один и тот же тестовый случай вручную или проверяем результат следующего ночного запуска, то обычно проблема решается автоматически, но иногда это происходит снова в совершенно другом месте. В случае некоторых прогонов такая проблема вообще не возникает. Самая большая проблема заключается в том, что ошибка не воспроизводится; кроме того, как это бывает в случае автоматического прогона, у нас практически нет информации о конкретных обстоятельствах, просто в тестовом случае и журнале.

Неужели кто-то уже сталкивался с такой проблемой? Вы не знаете, как это сделать? Любой намек или часть информации были бы полезны не только для решения проблемы. Спасибо!

Answer 1

Я нашел причину ошибки (99% уверен). Мы имели следующие 2 Jenkins работы:

1. Job1: Выполняет полную чистую сборку тестируемой системы, написанной на Java, а затем выполняет полную чистую сборку DSL, и, наконец, выполняет тестовые случаи. Это длительная работа (~ 5 часов).
2. Job2: Выполняет полную чистую сборку тестируемой системы, а затем выполняет на ней что-то еще. DSL не задействован. Это более короткая работа (~ 1 час).

У нас есть один репозиторий Maven для всех заданий. Кроме того, некоторые части тестируемого компонента являются частью интерфейса между двумя компонентами.

Учитывая временные метки произошло следующее:

1. Job1 выполнил полную сборку обоих компонентов, и начал тестовый набор, содержащий несколько тестовых случаев, исполнение которых длится около получаса.
2. Сборщик мусора мог вычеркнуть компоненты, которые еще не используются.
3. Job2 начал сборку, а также перестроил интерфейсные части, в том числе один, выметаемый сборщиком мусора Job1.
4. Job1 достиг тестового примера, в котором уже используется компонент интерфейса.

решение было следующее: мы переехали Job2 к более раннему времени; теперь он заканчивает работу до того, как начнутся тесты Job1.