«Tnameserv» Java занимает 3+ минуты, чтобы быть «готовым», почему? - PullRequest
Новая
       36

«Tnameserv» Java занимает 3+ минуты, чтобы быть «готовым», почему?

3 голосов
/ 16 декабря 2009

Я пытаюсь помочь разработчику приложения, которое я хотел бы использовать, решить проблему с использованием Corba Server в Linux. Я сузил проблему до tnameserv и занял 3 минуты, чтобы подготовиться после вызова.

Что именно tnameserv пытается сделать за эти 3 минуты, и могу ли я в любом случае ускорить его? Приложение не удалось, потому что оно попыталось сделать 5 попыток подключения с 1-секундной перерывом между попытками; который, очевидно, не дает tnameserv достаточно времени, чтобы подготовиться. Я использую Java 6u17 на Slackware 13.0

На случай, если это имеет значение. Фактический вызов tnameserv следующий: 

tnameserv -ORBInitialPort 23423

После запуска этой команды в оболочке она, кажется, зависает до отметки 3 минуты, когда я наконец вижу, что она отображает «Готово».

UPDATE

Я выполнил strace -f tnameserv -ORBInitialPort 23423, и я вижу множество вызовов gettimeofday (), clock_gettime () и futex (), из которых последний всегда возвращает -1 ETIMEDOUT (тайм-аут соединения). У меня такое чувство, что это связано с моей проблемой, но я понятия не имею, как и почему.

Вот лишь небольшая часть того, что я вижу от strace. Может ли кто-нибудь повторить и / или разобраться в этом? 

[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903084}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995857482}) = 0
[pid 30950] gettimeofday({1260930158, 92108}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995996617}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 996088536}) = 0
[pid 30950] gettimeofday({1260930158, 92328}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 92424295}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903705}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46761098}) = 0
[pid 30950] gettimeofday({1260930158, 143084}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46913924}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 47006961}) = 0
[pid 30950] gettimeofday({1260930158, 143303}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 143398317}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904683}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97818379}) = 0
[pid 30950] gettimeofday({1260930158, 194127}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97957235}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 98049154}) = 0
[pid 30950] gettimeofday({1260930158, 194346}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 194441349}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904651}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148806370}) = 0
[pid 30950] gettimeofday({1260930158, 245055}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148947182}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148981547}) = 0
[pid 30950] gettimeofday({1260930158, 245280}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 245374859}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49905141}) = -1 ETIMEDOUT (Connection timed out)

Ответы [ 3 ]

1 голос
/ 17 декабря 2009

Оказывается, проблема в брандмауэре. Wireshark не показал ничего полезного, потому что брандмауэр сбрасывал определенный пакет. Хотя я несколько раз просматривал логи своего брандмауэра, чтобы убедиться, что это не так, оказалось, что я искал не в том месте. Я упустил из виду тот факт, что этот tnameserv был осведомлен об IPv6 (поскольку он был связан с ::: 23423), и беглый взгляд на мой скрипт брандмауэра показал, что я регистрировал связанные с IPv6 пакеты в другом месте, чем мои пакеты IPv4. Это не было упущением, но должно было быть сделано, потому что ip6tables в настоящее время не поддерживает цель -j ULOG.

Короче говоря, петлевая петля для IPv6 устранила проблему, а tnameserv почти мгновенно возвращает "Ready".

1 голос
/ 16 декабря 2009

Я нашел это с помощью Google (кстати, сегодня день рождения Л.Л. Заменгофа). Я бы включил какую-нибудь трассировку проволочной акулы и посмотрел, можно ли там что-нибудь увидеть. Хотя я бы ожидал увидеть вещи в полосе, если бы была активность в сети. Жаль, что это не открытый исходный код.

0 голосов
/ 16 декабря 2009

Проверьте свои DNS-настройки. Вы можете ожидать ответа несколько раз.

...