Запуск Tomcat завершился неудачно из-за "java.net.SocketException Недопустимый аргумент" в Mac OS X

У нас есть приложение, которое работает на Tomcat 6 (6.0.35.0, если быть точным), и большинство наших инженеров на Mac OS испытывают проблемы с запуском Tomcat из-за вызова socketAccept в методе Catalina.await, бросающего SocketException:

Это приводит к тому, что Tomcat отключается сразу после запуска (и не имеет большого количества ярости). Мы думаем, что это было с нами на протяжении всего срока действия Mac OS с Java 1.7, за последние несколько месяцев многие из нас перешли на Macbook Pros. До сих пор единственным симптомом были случайные ответы с нулевым байтом от Tomcat, из-за этого исключения также бросали на socketRead. Ошибки не попадают в журналы, и мы индивидуально пожали плечами, как изолированная проблема, и обнаружили причину только при запуске проблемы с запуском, и я установил точку останова SocketException:

Проблема чувствительна к времени. Увеличение времени запуска из-за изменений в приложениях (более чем Spring introspection/singleton overhead), по-видимому, является фактором, который заставляет это влиять на запуск Tomcat; точка опрокидывания составляет около 160 секунд. Мы можем смягчить эту проблему, отключив некоторые необязательные контексты, которые нам не нужны во время разработки, чтобы сократить время запуска, но я бы предпочел найти основную причину.

Конфигурация приложения

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

Элементы исключены

Для тех, кто интересуется конфигурацией хостов, он аналогичен по умолчанию. Я могу воспроизвести это на Fusion VM с чистой установкой 10.8:

Исследование Java-кода

Из-за очевидного чувствительного к времени характера проблемы установка контрольных точек для устранения неполадок не приводит к ее возникновению. В соответствии с просьбой в комментариях я также взял arg0 для SocksSocketImpl(PlainSocketImpl).socketAccept(SocketImpl), ничего не выглядит необычным.

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

Это не объясняет, как и почему это может повлиять на несколько потоков, независимо от того, что мы делаем, чтобы вызвать это условие, таинственные SocketExceptions не должны пузыриться из собственного кода и вызывать эти исключения одновременно на нескольких потоках - это, два потока, вызывающие исходящие вызовы веб-сервисов, ожидание вызова Tomcat и несколько потоков процессора TP.

Исследование кода JNI

Учитывая общее сообщение, я предположил, что ошибка из EINVAL должна быть возвращена из одного из системных вызовов в коде socketSccept JNI, поэтому я проследил системные вызовы, ведущие к исключению; там нет EINVAL, возвращаемого с любого системного вызова. Итак, я пошел в источники OpenJDK, ища условия в коде socketAccept, который бы установил, а затем выбросил EINVAL, но я также не смог найти код, который устанавливает errno в EINVAL, или вызывает NET_ThrowByNameWithLastError, NET_ThrowCurrent или NET_ThrowNew таким образом, чтобы это исключение SocketException с этим сообщением об ошибке по умолчанию.

Что касается системных вызовов, мы, кажется, не дошли до системного вызова accept:

Итак, я думаю, что проблема возникает в коде обработки тайм-аута в верхней части цикла accept в socketAccept, но я не мог найти случай, когда NET_Timeout установил errno в EINVAL, и в результате возникает это SocketException. Я имею в виду этот код; Я полагаю, что ветвь jdk7u по большей части является судом в Oracle JDK:

Помогите!

Я не могу найти никого во внешнем мире, затронутого этой конкретной проблемой в Mac OS, но почти все здесь затронуты. Должна быть какая-то конфигурация приложения, которая способствует, но я исчерпал все возможности, которые я могу придумать, чтобы найти основную причину.

Указатели на устранение неполадок или понимание возможной причины были бы очень оценены.

Ответы

Ответ 1

Вы пробовали включить отладку JNI с помощью -Xcheck:jni? Интересно, что документация Oracle использует ошибку PlainSocketImpl.socketAccept в качестве примера того, когда использовать это.

Обратите внимание также, что подразумевается Ошибка 7131399, что JNI использует poll() на большинстве платформ, но select() на Mac OS из-за к проблеме с poll() на Mac. Так что, может быть, select() тоже сломано. Копаясь немного дальше, select() вернет EINVAL, если "ndfs больше, чем FD_SETSIZE и _DARWIN_UNLIMITED_SELECT не определено". FD_SETSIZE - 1024, и похоже, что у вас много загружаемых приложений, поэтому, возможно, все это фильтрует до ожидания более 1024 FDs за один раз.

Для получения дополнительной информации см. связанная (предположительно исправленная) ошибка Java на самом деле исправлена на вашем компьютере. Отчет об ошибке содержит указатели для проверки случаев.

Благодаря ответу Old Pro я подтвердил, что ограничение select() FD_SETSIZE является причиной. Я нашел существующую ошибку для этого ограничения:

https://bugs.openjdk.java.net/browse/JDK-8021820

Проблема может быть воспроизведена с помощью следующего кода:

import java.io.*;
import java.net.*;

public class SelectTest {
  public static void main(String[] args) throws Exception {
    // Use 1024 file descriptors. There'll already be some in use, obviously, but this guarantees the problem will occur
    for(int i = 0; i < 1024; i++) {
      new FileInputStream("/dev/null");
    }
    ServerSocket socket = new ServerSocket(8080);
    socket.accept();
  }
}

Почти год спустя Java 7u60 исправляет эту проблему:

http://www.oracle.com/technetwork/java/javase/2col/7u60-bugfixes-2202029.html

Я также обнаружил, что Tomcat WebappClassLoader закрывает дескрипторы файлов через 90 секунд, что объясняет, почему установка точек останова предотвратила возникновение проблемы.

Ответ 2

У меня была точно такая же проблема (с Tomcat7), и мне кажется, что для меня стоит отметить параметр "Опубликовать контекст модуля для разделения файлов XML", когда я запускаю tomcat внутри Eclipse. Вы уже пробовали это?

Ответ 4

Я боролся с этой проблемой в другом контексте. Решение (ы), объединенные из разных источников, выглядят следующим образом:

Обновить /etc/hosts со следующими переопределениями:
- :: 1 EWD-MacBook-Pro.local
- 127.0.0.1 EWD-MacBook-Pro.local localhost

(EWD-MacBook-Pro.local - мое имя машины)

Установить свойства системы:
- java.net.preferIPv4Stack = > true
- java.net.preferIPv6Addresses = > false

Удачи!