Java OOM в многопроцессной среде тестирования пригодности

мы используем пригодность для приемочного тестирования сложного веб-приложения. полный набор займет несколько часов, поэтому мы используем несколько процессов. установка следующая:

  1. maven forks серверный процесс фитнеса
  2. maven делает http-вызовы на фитнес-сервер
  3. фитнес-сервер разветвляет тестовый бегун для каждого вызова
  4. HTTP-вызов возвращается, вернитесь к 2.

командная строка для запуска jvm в 3. встроена в банку для фитнеса на основе параметров HTTP-вызова. это означает, что вы не можете передать произвольный аргумент jvm, только те, которые поддерживаются.

теперь проблема, с которой мы сталкиваемся, заключается в том, что иногда процесс запускался через 3 зависания. это не похоже на проблему тайм-аута, потому что мы видели, как они зависали в течение нескольких часов.

эти процессы jvm ничего не раскрывают через jmx, поэтому мы не можем подключиться к ним с помощью jconsole или аналогичного. исходя из объема памяти, который потребляет каждый процесс (1-1,5 ГБ), я сильно подозреваю, что OOM происходит где-то в процессе запуска и не позволяет ему нормально завершиться. Кроме того, попытка "убить -3" на серверном процессе приводит к

Exception in thread "CommandRunner stdOut" java.lang.OutOfMemoryError: Java heap space  at java.util.Arrays.copyOf(Arrays.java:3332)

в том, что кажется стандартным выводом из запущенного процесса бегуна, но я не уверен.

решение, о котором я сейчас думаю, - это создание моих копий классов, которые управляют командной строкой, чтобы каждый процесс запускался со случайным портом jmx и портом отладки, поэтому, если он зависает, можно подключиться и исследовать.

Итак, вопрос в том, есть ли лучший способ сделать это? я пропустил что-то очевидное здесь?


java remote-debugging fitnesse fitnesse-slim
person ilj    schedule 30.12.2016    source источник
comment
Вам нужен один процесс, который порождает тестировщиков? У меня есть аналогичный набор тестов, который я распараллелил, но каждый из моих под-наборов полностью независим. Может ли это работать для вас?   -  person Fried Hoeben    schedule 31.12.2016
comment
@FriedHoeben, в принципе может. но это означало бы, что я должен переписать все это. эта часть нашей тестовой инфраструктуры унаследована, и я не хочу тратить много времени на ее переписывание с нуля.   -  person ilj    schedule 01.01.2017

Ответы (1)


arrow_upward
0
arrow_downward

Я не верю, что ядро ​​FitNesse является потокобезопасным. Поэтому вместо того, чтобы сосредотачивать свои усилия на контроле запуска бегунов и их отладке, я рекомендую вам попробовать запустить свои тестовые процессы полностью изолированно друг от друга. Используя один процесс для FitNesse и средства запуска тестов (и несколько из них, когда вы хотите запускать наборы параллельно), также становится проще отлаживать, если есть какие-либо проблемы (поскольку вам не нужно контролировать создание дополнительные процессы и присоединяйтесь к этим новым процессам, есть только процесс для тестового прогона/набора).

Что я делаю, так это запускаю свои наборы тестов через средство запуска jUnit (которое использует один процесс для запуска как FitNesse, так и средства запуска тестов) и запускаю отдельный процесс (jUnit) для каждого набора тестов, который я хочу запускать параллельно. На самом деле я не контролирую создание процесса через maven, но использую несколько процессов в задании Jenkins. Каждый из них выполняет одну и ту же команду maven, но с разными системными свойствами, и одно из системных свойств определяет, какой пакет выполнять.

Использование такого подхода может быть слишком большим изменением для вашей тестовой установки. Но я считаю, что вы могли бы немного изменить свой процесс и получить аналогичные результаты. Вы не указали, как именно устроен ваш maven pom. Но не могли бы вы просто повторить шаги 1-4 для каждого набора, а не только шаги 2-4. Кажется, это просто требует изменения порта, который прослушивает сервер FitNesse (на шаге 1), и это легко сделать с помощью параметров командной строки (-p). Запуск в том же процессе, что и вики, должен быть возможен путем добавления &debug к URL-адресу, используемому на шаге 2.

person Fried Hoeben    schedule 01.01.2017