Как забытые JVM ломали наш CI (и как мы это починили)

Вот важная новость с фронта ИИ: chesnokoff 23 минуты назад Как забытые JVM ломали наш CI (и как мы это починили) Средний 7 мин 983 Блог компании Сбер Тестирование IT-систем * IT-инфраструктура * Кейс Привет, Хабр! Меня зовут Александр Чесноков, я разработчик команды Platform V DataGrid в СберТехе. Наш продукт — форк Apache Ignite с нашими доработками, и мы активно поддерживаем open‑source версию: контрибьютим в основной репозиторий, исправляем баги, развиваем новые фичи, а также поддерживаем инфраструктуру для тестирования.

В этой статье расскажу, как в Ignite мы столкнулись с orphan JVM на тестовых стендах, как они поломали нам тестирование и как мы решили эту проблему, научив дочерние JVM отслеживать завершение родителя через pipe, используя System. В конце разберем конкретную реализацию решения. Статья будет полезна тем, кто работает с CI, интеграционными тестами, или запускает дочерние процессы в своих приложениях.

Технические детали

Apache IgniteApache Ignite — это распределённая in‑memory-система баз данных, поддерживающая datagrid-операции и написанная на Java. Каждый pull request от контрибьюторов идёт сразу в master, поэтому мы прогоняем каждый патч через тесты на TeamCity. У нас более 80 000 тестов, в основном интеграционных.

Типичный сценарий: подняли серверный или клиентский узел Ignite, выполнили на нём операции и сравниваем полученные результаты с нашими ожиданиями. Если хочется глубже погрузиться в тему CI и тестирования в Apache Ignite, то мы уже рассказывали об этом на Хабре — например, как боремся с flaky‑тестами и поддерживаем стабильность прогонов. Отдельно отмечу совместимость: в Apache Ignite мы заботимся о поддержке взаимодействия различных версий продукта.

Например, у нас есть понятие тонкого клиента — это клиентская нода в Ignite, которая может подключаться к серверной ноде любой версии. Также мы сейчас активно разрабатываем механизм Rolling Upgrade, когда в кластере могут одновременно быть серверные ноды двух разных версий. Такая функциональность позволит обновлять кластер без полной остановки.

Отраслевые последствия

Чтобы поддерживать совместимость, у нас есть соответствующие тесты. Типичный сценарий выглядит так: в исходной JVM запускаем тест, который запускает клиентскую или серверную ноду, а затем — новую JVM в дочернем процессе, где уже запускается нода старой версии. Старая нода выполняет некие операции, может подключиться к новой, и мы проверяем, чтобы поведение соответствало ожиданиям.

Если старая нода падает, то родительская JVM по таймауту завершает запущенный процесс в блоке finally.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.