Поведение веб-сервера Grizzly JerseyTest на Unix

Question

Мы создали набор тестов и для его запуска используем встроенный веб-сервер Grizzly с инфраструктурой JerseyTest.

Мы расширяем пользовательский класс из JerseyTest, и в его конструкторе мы создаем ApplicationDescriptor, а затем вызываем суперкласс setupTestEnvironment (), который по существу запускает встроенный веб-сервер гризли.

Лишь немногие из наших тестовых примеров расширяют этот пользовательский класс для непосредственного запуска сервера гризли. Однако мы нигде не останавливаем этот встроенный сервер в коде.

Тестовые случаи хорошо работают в Windows, но в Unix они терпят неудачу с java.net.BindException порт 9998 используется другим процессом.

Становится очевидным, что эти тесты должны проваливаться с похожей ошибкой на окнах, если мы не останавливаем встроенный веб-сервер в коде. Как они работают нормально на Windows и не работают на Unix. Это как-то связано с тем, как Unix порождает потоки или процессы?

P.S. Мы также проверили, используется ли порт 9998 каким-либо другим процессом с помощью netstat -a | grep 9998, но не удалось найти другой процесс, использующий этот порт.

Answer 1

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

@Override
protected int getPort(int defaultPort) {

    ServerSocket server = null;
    int port = -1;
    try {
        server = new ServerSocket(defaultPort);
        port = server.getLocalPort();
    } catch (IOException e) {
        // ignore
    } finally {
        if (server != null) {
            try {
                server.close();
            } catch (IOException e) {
                // ignore
            }
        }
    }
    if ((port != -1) || (defaultPort == 0)) {
        return port;
    }
    return getPort(0);
}

Answer 2

У меня была такая же проблема, когда я писал свои интеграционные тесты. Я не смог протестировать на компьютере с Windows, но на своем компьютере с Unix обнаружил, что проблема в том, что по умолчанию класс JerseyTest использует @After в своем методе tearDown для закрытия встроенного сервера. Поскольку я переопределил этот метод для очистки на моей стороне, мне пришлось вызвать super.tearDown()

@After
public void tearDown() throws Exception{
    super.tearDown();
    ...
}

После этого все заработало как положено.